Secure dynamic communication network and protocol

Abstract

In a secure cloud for transmitting packets of digital data, the packets may be repeatedly scrambled (i.e., their data segments reordered) and then unscrambled, split and then mixed, and/or encrypted and then decrypted as they pass through media nodes in the cloud. The methods used to scramble, split, mix and encrypt the packets may be varied in accordance with a state such as time, thereby making the task of a hacker virtually impossible inasmuch as he or she may be viewing only a fragment of a packet and the methods used to disguise the data are constantly changing.

Claims

1. A method of transmitting packets containing digital data through a cloud, the cloud comprising a network of media nodes, said media nodes being hosted on servers, each of the media nodes receiving packets from other media nodes in the cloud and transmitting packets to other media nodes in the cloud, each of the packets comprising a plurality of data segments, the method comprising: scrambling a packet by changing an order of the data segments in the packet in a first media node in accordance with a first scrambling algorithm; transmitting the packet to a second media node; unscrambling the packet in the second media node so as to recreate the order of the data segments in said packet prior to said scrambling in said first media node; after said unscrambling in said second media node, scrambling the packet in said second media node in accordance with a second scrambling algorithm; and transmitting said packet to a third media node, said second scrambling algorithm being different from said first scrambling algorithm such that the order of the data segments in the packet when the packet arrives at the third media node is different from the order of the data segments in the packet when the packet arrived at the second media node.

2. The method of claim 1 wherein said cloud comprises a plurality of gateway media nodes, each of said gateway media nodes being a media node connected to a client device via a last mile connection, and wherein at least one of said first and second media nodes is not a gateway media node.

3. The method of claim 2 wherein said first scrambling algorithm is determined by a value of a state.

4. The method of claim 3 wherein said value of said state is determined by a time at which said packet is scrambled in said first media node.

5. The method of claim 3 wherein said value of said state is determined by a zone in which said first media node is located.

6. The method of claim 3 wherein a first DMZ server is associated with said first media node and a second DMZ server is associated with said second media node, each of said first and second DMZ servers being isolated such that neither of said first and second media nodes is able to access files stored on either of said first and second DMZ servers, the method further comprising transmitting data representing a first value of said state from said first media node to said second DMZ server.

7. The method of claim 6 further comprising providing said second DMZ server with a selector, said selector containing a list of scrambling algorithms stored in a computer memory.

8. The method of claim 7 wherein said second DMZ server uses said data representing said first value of said state to select said first scrambling algorithm from said list of scrambling algorithms in said selector.

9. The method of claim 8 further comprising transmitting said first scrambling algorithm selected by said second DMZ server to said second media node, said second media node using said first scrambling algorithm to unscramble said packet.

10. The method of claim 7 wherein said data representing said value of said state comprises a seed, said seed containing a disguised representation of said value of said state.

11. The method of claim 7 wherein said second DMZ server comprises a hidden number generator, said hidden number generator using a hidden number algorithm to calculate a hidden number from said data representing said value of said state, said hidden number being used to select said first scrambling algorithm in said selector in said second DMZ server.

12. The method of claim 7 wherein said first DMZ server uses said first value of said state to select said first scrambling algorithm from a selector within said first DMZ server and transmits said first scrambling algorithm to first media node, thereby enabling said first media node to scramble said packet.

13. The method of claim 7 wherein said second DMZ server uses a second value of said state to select said second scrambling algorithm from said list of scrambling algorithms in said selector in said second DMZ server and transmits said second scrambling algorithm to said second media node, thereby enabling said second media node to scramble said packet.

14. A method of transmitting a packet containing digital data across a network, the network comprising: a plurality of media nodes, the media nodes being hosted on respective servers, each of the media nodes receiving packets from other media nodes in the network and transmitting packets to other media nodes in the network, each of the packets comprising a plurality of data segments, said packet passing through a first media node, a second media node, and one or more intermediate media nodes between said first media node and said second media node; the method comprising: scrambling said packet in said first media node; rescrambling said packet in at least some of said intermediate nodes, said rescrambling comprising unscrambling and then scrambling said packet; and unscrambling said packet in said second media node after said packet has been received by said second media node, wherein a scrambling algorithm used to scramble said packet in each of said media nodes in which said packet is scrambled is different from a scrambling algorithm used to scramble said packet in every other media node in which said packet is scrambled.

15. The method of claim 14 comprising rescrambling said packet in each of said intermediate media nodes.

16. The method of claim 14 wherein a scrambling algorithm used to scramble said packet in each of said media nodes in which said packet is scrambled is determined by a time at which said scrambling occurs.

17. A method of transmitting packets containing digital data through a cloud, the cloud comprising a network of media nodes, said media nodes comprising a plurality of gateway media nodes, each of said gateway media nodes being connected to a client device via a last mile connection, said media nodes being hosted on servers, each of the media nodes receiving packets from other media nodes in the cloud and transmitting packets to other media nodes in the cloud, each of the packets comprising a plurality of data segments, the method comprising: encrypting data in a packet in a first media node in accordance with a first encryption method, said first encryption method being determined by a value of a state; transmitting the packet to a second media node; and after the packet has been received by the second media node, decrypting the encrypted data in the packet in the second media node so as to recreate said packet prior to said encrypting in said first media node, wherein at least one of said first and second media nodes is not a gateway media node.

18. The method of claim 17 further comprising, after said decrypting in said second media node, encrypting data in the packet in said second media node.

19. The method of claim 17 wherein encrypting data in a packet in a first media node in accordance with a first encryption method comprises using an encryption algorithm and an encryption key.

20. The method of claim 18 wherein said encrypting in said first media node is performed in accordance with a first encryption method and said encrypting in said second media node is performed in accordance with a second encryption method, said second encryption method being different from said first encryption method.

21. The method of claim 20 wherein said value of said state is determined by a time at which said packet is encrypted in said first media node.

22. The method of claim 20 wherein said value of said state is determined by a zone in which said first media node is located.

23. The method of claim 20 wherein a first DMZ server is associated with said first media node and a second DMZ server is associated with said second media node, each of said first and second DMZ servers being isolated such that neither of said first and second media nodes is able to access files stored on either of said first and second DMZ servers, the method further comprising transmitting data representing a first value of said state from said first media node to said second DMZ server.

24. The method of claim 23 further comprising providing said second DMZ server with a selector, said selector containing a list of encryption methods stored in a computer memory.

25. The method of claim 24 wherein said second DMZ server uses said data representing said first value of said state to select said first encryption method from said list of encryption methods in said selector.

26. The method of claim 25 further comprising transmitting said first encryption method selected by said second DMZ server to said second media node, said second media node using said first encryption method to decrypt said encrypted data in said packet.

27. The method of claim 24 wherein said data representing said value of said state comprises a seed, said seed containing a disguised representation of said value of said state.

28. The method of claim 24 wherein said second DMZ server comprises a hidden number generator, said hidden number generator using a hidden number algorithm to calculate a hidden number from said data representing said value of said state, said hidden number being used to select said first encryption method in said selector in said second DMZ server.

29. The method of claim 24 wherein said first DMZ server uses said first value of said state to select said first encryption method from a selector within said first DMZ server and transmits said first encryption method to first media node, thereby enabling said first media node to encrypt data in said packet.

30. The method of claim 24 wherein said second DMZ server uses a second value of said state to select said second encryption method from said list of encryption methods in said selector in said second DMZ server and transmits said second encryption method to said second media node, thereby enabling said second media node to encrypt said packet using said second encryption method.

31. A method of transmitting a packet containing digital data across a network of media nodes, the media nodes being hosted on respective servers, each of the media nodes receiving packets from other media nodes in the network and transmitting packets to other media nodes in the network, each of the packets comprising a plurality of data segments, said packet passing through a first media node, a second media node, and one or more intermediate media nodes between said first media node and said second media node, the method comprising: encrypting data in said packet in said first media node; re-encrypting said packet in at least some of said intermediate media nodes, said re-encrypting comprising decrypting data in said packet and then encrypting data in said packet; and decrypting data in said packet in said second media node, wherein an encryption method used to encrypt data in said packet in each of said media nodes in which data in said packet is encrypted is different from an encryption method used in encrypting data in said packet in every other media node in which data in said packet is encrypted.

32. The method of claim 31 comprising re-encrypting said packet in each of said intermediate media nodes.

33. The method of claim 31 wherein an encryption method used to encrypt data in said packet in each of said media nodes in which data in said packet is encrypted is determined by a time at which said encryption occurs.

34. The method of claim 31 wherein an encryption method used to encrypt data in said packet in each of said media nodes in which data in said packet is encrypted comprises using an encryption algorithm and an encryption key.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) In the drawings listed below, components that are generally similar are given like reference numerals. It is noted, however, that not every component to which a given reference number is assigned is necessarily identical to another component having the same reference number. For example, an encryption operation having a particular reference number is not necessarily identical to another encryption operation with the same reference number. Furthermore, groups of components. e.g., servers in a network that are identified collectively by a single reference number are not necessarily identical to each other.

(2) FIG. 1 is a schematic representation of a circuit-based telephonic network.

(3) FIG. 2 is a schematic representation of a packet-based communication network.

(4) FIG. 3 is a schematic representation of packet routing in a packet-based communication network.

(5) FIG. 4 is a graphical representation of the construction of an IP packet for communication over a packet-switched network.

(6) FIG. 5A is a schematic representation of a communication network illustrating high-bandwidth connectivity examples of physical Layer 1.

(7) FIG. 5B is a schematic representation of a communication network illustrating last-mile connectivity examples of physical Layer 1.

(8) FIG. 6A is a schematic representation of a physical Layer 1 connection between two devices.

(9) FIG. 6B is a schematic representation of a shared physical Layer 1 connection among three devices.

(10) FIG. 7A is a schematic representation of a data link Layer 2 connection among three devices using a bus architecture.

(11) FIG. 7B is a schematic representation of a data link Layer 2 connection among three devices using a hub architecture.

(12) FIG. 7C is a schematic representation of a data link Layer 2 connection among three devices using a daisy chain architecture.

(13) FIG. 8A is a schematic representation of a data link Layer 2 connection among three devices including a network switch.

(14) FIG. 8B is a simplified schematic representation of network switch.

(15) FIG. 8C is a schematic representation of the operation of a network switch.

(16) FIG. 9 is a graphical representation of a data link Layer 2 construct of an IP packet using an Ethernet protocol.

(17) FIG. 10 is a simplified schematic representation of Ethernet-to-radio network-bridge.

(18) FIG. 11 is a graphical representation of the data link Layer 2 construct of a IP packet using WiFi protocol.

(19) FIG. 12A is a schematic representation of the bidirectional operation of a WiFi network access point.

(20) FIG. 12B is a schematic representation of the bidirectional operation of a WiFi repeater.

(21) FIG. 13 is a graphical representation of the evolution of telephonic, text, and data communication over cellular networks.

(22) FIG. 14A is a graphical representation of frequency partitioning in 4G/LTE communication networks.

(23) FIG. 14B is a graphical representation of OFDM encoding used in 4G/LTE radio communication.

(24) FIG. 15 is a graphical representation of the Layer 2 data link construct of an IP packet using 4G/LTE protocol.

(25) FIG. 16 is a schematic representation of cable modem communication network.

(26) FIG. 17 is a schematic representation of the data link Layer 2 construct of a cable modem communication network.

(27) FIG. 18 is a graphical representation of trellis encoding used in DOCSIS based cable modems.

(28) FIG. 19 is a graphical representation of the data link Layer 2 construct of a communication packet using DOCSIS protocol.

(29) FIG. 20 is a schematic representation of a network Layer-3 connection among three devices.

(30) FIG. 21 is a graphical representation of communication packets encapsulated in accordance with the 7-layer OSI model.

(31) FIG. 22 is a graphical representation of the network Layer-3 construct comparing communication packets for IPv4 and IPv6.

(32) FIG. 23 is a graphical representation of an IP packet in accordance with IPv4 protocol.

(33) FIG. 24 is a graphical representation of an IP packet in accordance with IPv6 protocol.

(34) FIG. 25 is a graphical representation of the address fields constructed in accordance with IPv4 and IPv6 protocols.

(35) FIG. 26 is a graphical representation of the protocol/next header field in an IP packet and its corresponding payload.

(36) FIG. 27 is a schematic representation of a transport Layer-4 connection among three devices.

(37) FIG. 28A is a graphical representation of a transport Layer 4 construct of a IP packet using TCP protocol.

(38) FIG. 28B is a table describing the fields of the TCP protocol.

(39) FIG. 29 is a graphical representation of a TCP packet transfer sequence.

(40) FIG. 30 is a graphical representation of a transport Layer 4 construct of a IP packet using UDP protocol.

(41) FIG. 31A is a schematic representation of transport Layer 4 communication from client to host.

(42) FIG. 31B is a schematic representation of transport Layer 4 communication from host to client.

(43) FIG. 31C is a table describing common UDP and TCP port allocations.

(44) FIG. 31D is a table describing allocated blocks for reserved and ad hoc port addresses used by UDP and TCP.

(45) FIG. 32A is a schematic representation of a network application translator (NAT).

(46) FIG. 32B is a schematic representation of the operation of a network application translator.

(47) FIG. 33 is a schematic representation of three devices connected with application Layer 5, Layer 6, and Layer 7.

(48) FIG. 34 is a schematic representation of content download using the Layer 7 application for file transfer protocol (HTTP).

(49) FIG. 35A is a schematic representation of web page downloads using the Layer 7 application for using hypertext transfer protocol or HTTP.

(50) FIG. 35B is a graphical representation of a HTML web page constructed from downloads from various servers.

(51) FIG. 36 is a schematic representation of Layer 7 application for IMAP-based email.

(52) FIG. 37 is a table comparing quality of service (QoS) for varying network conditions.

(53) FIG. 38 is a graph of the round-trip time (RTT) as a function of network's intra-node propagation delay.

(54) FIG. 39 is a schematic diagram of various examples of malware in a communication network.

(55) FIG. 40 is simplified representation of cloud and last-mile network connectivity and malware used in cyber-assaults.

(56) FIG. 41A illustrates electronic devices capable of monitoring Ethernet and WiFi communication.

(57) FIG. 41B illustrates electronic devices capable of monitoring cell phone communication.

(58) FIG. 41C illustrates an electronic device capable of monitoring optical fiber communication.

(59) FIG. 42 is a table comparing ten commercially available spyware program features.

(60) FIG. 43 is a world map showing cyber-assault incidents in one single day.

(61) FIG. 44 illustrates possible IP packet sniffing and man-in-middle-attacks on a packet-switched network.

(62) FIG. 45 illustrates a cyber-assault using port interrogation based discovery.

(63) FIG. 46 illustrates a cyber-assault employing IP packet hijacking.

(64) FIG. 47 is a schematic representation of dual key encryption.

(65) FIG. 48A is a schematic representation of a virtual private network.

(66) FIG. 48B illustrates the communication stack of a virtual private network.

(67) FIG. 48C is a schematic diagram showing a VoIP call placed over an ad hoc VPN.

(68) FIG. 49A is a schematic diagram showing a over-the-top VoIP call placed over the Internet.

(69) FIG. 49B is a schematic diagram showing a VoIP call placed over a peer-to-peer network.

(70) FIG. 50 is a schematic diagram showing conventional packet transport across a network.

(71) FIG. 51A is a schematic diagram showing the process of packet scrambling.

(72) FIG. 51B is a schematic diagram showing the process of packet unscrambling.

(73) FIG. 51C is a schematic diagram showing various packet scrambling algorithms.

(74) FIG. 51D is a schematic diagram showing static parametric packet scrambling.

(75) FIG. 51E is a schematic diagram showing dynamic scrambling with a hidden number.

(76) FIG. 51F is a schematic diagram showing dynamic packet scrambling using dithering.

(77) FIG. 52 is a schematic diagram showing static packet scrambling in a linear network.

(78) FIG. 53 is a schematic diagram showing the packet re-scrambling process.

(79) FIG. 54 is a schematic diagram showing dynamic packet scrambling in a linear network.

(80) FIG. 55A is a schematic diagram showing the process of packet encryption.

(81) FIG. 55B is a schematic diagram showing the process of packet decryption.

(82) FIG. 56 is a schematic diagram showing the process of encrypted scrambling and its inverse function.

(83) FIG. 57 is a schematic diagram showing static encrypted scrambling in a linear network.

(84) FIG. 58 is a schematic diagram showing the process of DUSE re-packeting comprising re-scrambling and re-encryption.

(85) FIG. 59 is a schematic diagram showing dynamic encrypted scrambling in a linear network.

(86) FIG. 60A is a schematic diagram showing the process of fixed-length packet splitting.

(87) FIG. 60B is a schematic diagram showing the process of fixed-length packet mixing

(88) FIG. 61A is a schematic diagram showing various packet-mixing methods.

(89) FIG. 61B is a schematic diagram showing concatenated packet mixing.

(90) FIG. 61C is a schematic diagram showing interleaved packet mixing.

(91) FIG. 62A is a schematic diagram showing a mix then scramble method.

(92) FIG. 62B is a schematic diagram showing a scramble then mix method.

(93) FIG. 63 is a schematic diagram showing static scrambled mixing in a linear network.

(94) FIG. 64 is a schematic diagram showing dynamic scrambled mixing in a linear network.

(95) FIG. 65 is a schematic diagram depicting various encrypted packet processes.

(96) FIG. 66A is a schematic diagram showing dynamic encrypted scrambled mixing in a linear network.

(97) FIG. 66B is a schematic diagram showing static scrambled mixing with dynamic encryption in a linear network.

(98) FIG. 66C is a schematic diagram showing dynamic mixing scrambling and encryption in a linear network using the return to normal method.

(99) FIG. 66D is a schematic detailing the DUS-MSE return-to-normal method.

(100) FIG. 67A is a schematic diagram showing single-output packet mixing.

(101) FIG. 67B is a schematic diagram showing multiple-output packet mixing.

(102) FIG. 67C is a schematic diagram showing variable length packet splitting.

(103) FIG. 67D is a schematic diagram showing fixed-length packet splitting.

(104) FIG. 67E is a flow chart illustrating a mixing algorithm.

(105) FIG. 67F is a flow chart illustrating a splitting algorithm.

(106) FIG. 67G is a flow chart illustrating a two-step mixing and scrambling algorithm.

(107) FIG. 67H is a flow chart illustrating a hybrid mixing/scrambling algorithm.

(108) FIG. 67I is a flow chart illustrating tag identification.

(109) FIG. 67J is a flow chart illustrating the injection of junk data into the sub-packets.

(110) FIG. 68A is a schematic diagram depicting various types of packet routing.

(111) FIG. 68B is a schematic diagram depicting single route or linear transport.

(112) FIG. 68C is a schematic diagram depicting multi-route or parallel transport.

(113) FIG. 68D is a schematic diagram depicting meshed route transport.

(114) FIG. 68E is a schematic diagram depicting an alternate embodiment of meshed route transport.

(115) FIG. 69 is a schematic diagram showing static multi-route transport.

(116) FIG. 70 is a schematic diagram showing static multi-route scrambling.

(117) FIG. 71A is a schematic diagram showing dynamic multi-route scrambling.

(118) FIG. 71B is a schematic diagram depicting various combinations of scrambling and splitting.

(119) FIG. 71C is a schematic diagram depicting nested mixing, splitting, scrambling and encryption.

(120) FIG. 72 is a schematic diagram showing static scramble then split & dynamically encrypt method.

(121) FIG. 73 is a schematic diagram showing static scrambled multiroute transport with dynamic encryption.

(122) FIG. 74 is a schematic diagram depicting various combinations of split, scramble, and encrypt methods.

(123) FIG. 75 is a schematic diagram showing variable-length static meshed routing.

(124) FIG. 76 is a schematic diagram showing variable-length static scrambled meshed routing.

(125) FIG. 77A is a schematic diagram showing variable-length mix and split operation for meshed transport.

(126) FIG. 77B is a schematic diagram showing a fixed-length mix and split operation for meshed transport.

(127) FIG. 77C is a schematic diagram showing various combinations of communication node connectivity in a meshed network.

(128) FIG. 77D is a schematic diagram depicting non-planar meshed network node connectivity.

(129) FIG. 78A is a schematic diagram showing re-scrambled mixing and splitting.

(130) FIG. 78B is a schematic diagram showing an unscrambled mix of meshed inputs.

(131) FIG. 78C is a schematic diagram showing a split-and-scramble operation for meshed outputs.

(132) FIG. 78D is a schematic diagram showing re-scramble and remix for meshed transport.

(133) FIG. 79A is a schematic diagram showing fixed-length scrambled mix and split for meshed transport.

(134) FIG. 79B is a schematic diagram showing an alternate embodiment of fixed-length scrambled mix and split for meshed transport

(135) FIG. 80 is a schematic diagram showing variable-length static scrambled meshed routing.

(136) FIG. 81A is a schematic diagram showing encrypted mixing and splitting.

(137) FIG. 81B is a schematic diagram showing decrypted mixing of meshed inputs.

(138) FIG. 81C is a schematic diagram showing split and encrypt for meshed outputs.

(139) FIG. 82A is a schematic diagram showing a re-scrambling encrypted packet for meshed transport.

(140) FIG. 82B is a schematic diagram showing a decrypt, unscramble and mix (DUM) operation for meshed inputs.

(141) FIG. 82C is a schematic diagram showing a split, scramble, and encrypt (SSE) operation for meshed outputs.

(142) FIG. 83A is a schematic diagram showing a SDNP media node for meshed transport.

(143) FIG. 83B is a schematic diagram showing a single-route SDNP media node.

(144) FIG. 83C is a schematic diagram showing a single-route pass-through SDNP media node.

(145) FIG. 83D is a schematic diagram showing a SDNP media node for redundant route replication.

(146) FIG. 83E is a schematic diagram showing a SDNP media node performing single-route scrambling.

(147) FIG. 83F is a schematic diagram showing a SDNP media node performing single-route unscrambling.

(148) FIG. 83G is a schematic diagram showing a SDNP media node performing single-route re-scrambling.

(149) FIG. 83H is a schematic diagram showing a SDNP media node performing single-route encryption.

(150) FIG. 83I is a schematic diagram showing a SDNP media node performing single-route decryption.

(151) FIG. 83J is a schematic diagram showing a SDNP media node performing single-route re-encryption.

(152) FIG. 83K is a schematic diagram showing a SDNP media node performing single-route scrambled encryption.

(153) FIG. 83L is a schematic diagram showing a SDNP media node performing single-route unscrambled decryption.

(154) FIG. 83M is a schematic diagram showing a SDNP media node performing single-route re-packeting.

(155) FIG. 83N is a schematic diagram showing a meshed SDNP gateway input.

(156) FIG. 83O is a schematic diagram showing a meshed SDNP gateway output.

(157) FIG. 83P is a schematic diagram showing a scrambled SDNP gateway input and an unscrambled SDNP gateway output.

(158) FIG. 83Q is a schematic diagram showing an encrypted SDNP gateway input and a decrypted SDNP gateway output.

(159) FIG. 83R is a schematic diagram showing a scrambled encrypted SDNP gateway input and an unscrambled decrypted SDNP gateway output.

(160) FIG. 83S is a schematic diagram showing SDNP gateways performing meshed re-scrambling and meshed re-encryption

(161) FIG. 84A is a schematic diagram showing SDNP media node interconnections.

(162) FIG. 84B is a schematic diagram showing an SDNP cloud.

(163) FIG. 84C is a schematic diagram showing an encrypted communication between SDNP media nodes.

(164) FIG. 84D is a schematic diagram showing SDNP internode encrypted communication.

(165) FIG. 85A is a schematic diagram showing a SDNP cloud with last-mile connectivity to a cell phone client.

(166) FIG. 85B is a schematic diagram showing a SDNP gateway with an unsecured last-mile connection.

(167) FIG. 85C is a schematic diagram showing a SDNP gateway with a secure last-mile connection.

(168) FIG. 85D is a schematic diagram showing an alternate embodiment of an SDNP gateway with a secure last-mile connection.

(169) FIG. 86 is a schematic diagram depicting various clients connected to a SDNP cloud.

(170) FIG. 87 is a schematic diagram packet routing in an SDNP cloud.

(171) FIG. 88A is a schematic diagram showing packet routing commencing in an SDNP cloud.

(172) FIG. 88B is a schematic diagram showing first cloud hop packet routing in an SDNP cloud.

(173) FIG. 88C is a schematic diagram showing second cloud hop packet routing in an SDNP cloud

(174) FIG. 88D is a schematic diagram showing third cloud hop packet routing in an SDNP cloud.

(175) FIG. 88E is a schematic diagram showing packet routing from an SDNP cloud gateway.

(176) FIG. 88F is a schematic diagram summarizing packet routing in an SDNP cloud for a specific session.

(177) FIG. 89A is a schematic diagram showing packet routing of an alternate session commencing in an SDNP cloud.

(178) FIG. 89B is a schematic diagram showing first cloud hop of an alternate session packet routing in an SDNP cloud.

(179) FIG. 89C is a schematic diagram showing second cloud hop of an alternate session packet routing in an SDNP cloud.

(180) FIG. 89D is a schematic diagram showing third cloud hop of an alternate session packet routing in an SDNP cloud.

(181) FIG. 89E is a schematic diagram showing fourth cloud hop of an alternate session packet routing in an SDNP cloud.

(182) FIG. 89F is a schematic diagram showing of an alternate session packet routing from an SDNP cloud gateway.

(183) FIG. 89G is a schematic diagram summarizing alternate session packet routing in an SDNP cloud.

(184) FIG. 90 is a schematic diagram showing SDNP packet content available to man-in-the-middle attacks and packet sniffing.

(185) FIG. 91A is a schematic diagram graphically representing SDNP packet transport over time.

(186) FIG. 91B is a schematic diagram representing SDNP packet transport over time in tabular form

(187) FIG. 91C is a schematic diagram graphically representing an SDNP packet of an alternate session packet transported over time.

(188) FIG. 92A is a schematic diagram showing control of incoming SDNP packets to SDNP media node.

(189) FIG. 92B is a schematic diagram showing control of outgoing SDNP packets from SDNP media node.

(190) FIG. 93 is a schematic diagram showing SDNP algorithm selection.

(191) FIG. 94 is a schematic diagram showing regular SDNP algorithm shuffling.

(192) FIG. 95A is a schematic diagram showing a multi-zone SDNP cloud.

(193) FIG. 95B is a schematic diagram showing SDNP multi-zone security management.

(194) FIG. 95C is a schematic diagram showing multi-zone full-duplex SDNP bridge.

(195) FIG. 95D is a schematic diagram showing a multi-zone SDNP network comprising multiple clouds.

(196) FIG. 95E is a schematic diagram depicting an unsecured link between SDNP clouds.

(197) FIG. 95F is a schematic diagram showing the use of multi-zone full-duplex SDNP bridges for secure cloud-to-cloud links.

(198) FIG. 96A is a schematic diagram showing a secure SDNP gateway and last-mile link to tablet client.

(199) FIG. 96B is a schematic diagram showing the cloud interface functions.

(200) FIG. 96C is a schematic diagram showing the client interface functions.

(201) FIG. 96D is a schematic diagram showing the client functions.

(202) FIG. 97A is a schematic diagram showing functional elements of a secure SDNP cloud gateway.

(203) FIG. 97B is a schematic diagram showing interconnection of functional elements in a secure SDNP cloud gateway.

(204) FIG. 98 is a schematic diagram showing the client interface in a secure SDNP cloud gateway.

(205) FIG. 99A is a schematic diagram showing key management in multi-zone transport.

(206) FIG. 99B is a schematic diagram showing key management in multi-zone transport with scrambled SDNP cloud transport.

(207) FIG. 99C is a schematic diagram showing key management in multi-zone transport with scrambled transport for SDNP and single last-mile route.

(208) FIG. 99D is a schematic diagram showing key management in multi-zone transport with end-to-end scrambling.

(209) FIG. 99E is a schematic diagram showing key management in multi-zone transport with scrambled transport for SDNP and single re-scrambled last-mile route.

(210) FIG. 99F is a schematic diagram showing key management in multi-zone transport with zone specific re-scrambling.

(211) FIG. 100A is a schematic diagram showing SDNP code delivery and installation.

(212) FIG. 100B is a schematic diagram showing SDNP code delivery and multi-zone installation.

(213) FIG. 101A is a schematic diagram showing delivery of SDNP secrets to a DMZ server.

(214) FIG. 101B is a schematic diagram showing secret-based media channel communication.

(215) FIG. 101C is a schematic diagram showing secret and key delivery by SDNP media channel.

(216) FIG. 102 is a schematic diagram showing dynamic SDNP control through an SDNP signaling server.

(217) FIG. 103A is a schematic diagram showing SDNP key and seed delivery through an SDNP signaling server.

(218) FIG. 103B is a schematic diagram showing an alternate embodiment of SDNP key and seed deliver), through an SDNP signaling server.

(219) FIG. 104 is a schematic diagram showing SDNP delivery to a client.

(220) FIG. 105A is a schematic diagram showing single-channel SDNP key and seed delivery to a client.

(221) FIG. 105B is a schematic diagram showing an alternate embodiment of single-channel SDNP key and seed delivery to a client.

(222) FIG. 106 is a schematic diagram showing client SDNP algorithm shuffling.

(223) FIG. 107 is a schematic diagram showing dual-channel SDNP key and seed delivery to client.

(224) FIG. 108 is a schematic diagram showing public key delivery to an SDNP client.

(225) FIG. 109 is a schematic diagram showing single-channel SDNP meshed transport.

(226) FIG. 110A is a flow chart showing media-channel SDNP ad hoc communication, part 1.

(227) FIG. 110B is a flow chart showing media-channel SDNP ad hoc communication, part 2.

(228) FIG. 110C is a flow chart showing media-channel SDNP ad hoc communication, part 3.

(229) FIG. 110D is a flow chart showing media-channel SDNP ad hoc communication, part 4.

(230) FIG. 110E is a flow chart showing media-channel SDNP ad hoc communication, part 5.

(231) FIG. 110F is a flow chart showing media-channel SDNP ad hoc communication, part 6.

(232) FIG. 111A is a flow chart summarizing SDNP ad hoc packet sending sequence.

(233) FIG. 111B is a network map summarizing SDNP sending routing.

(234) FIG. 112A is a flow chart summarizing SDNP ad hoc packet reply sequence.

(235) FIG. 112B is a network map summarizing SDNP reply routing.

(236) FIG. 113A is a schematic diagram showing SDNP packet preparation.

(237) FIG. 113B is a schematic diagram showing an alternate embodiment of SDNP packet preparation.

(238) FIG. 114 is a table summarizing one embodiment of the SDNP packet architecture.

(239) FIG. 115 is a schematic diagram showing an embodiment of dual-channel SDNP meshed transport wherein the signaling function within the cloud is performed by the same servers that act as media nodes and the signaling function in the first and last miles is performed by separate signaling servers.

(240) FIG. 116 is a schematic diagram showing an alternate embodiment of dual-channel SDNP meshed transport wherein the signaling function both in the cloud and in the first and last miles is performed by separate signaling servers.

(241) FIG. 117 is a schematic diagram showing tri-channel SDNP meshed transport.

(242) FIG. 118 is a schematic diagram showing SDNP node and device registration.

(243) FIG. 119 is a schematic diagram showing SDNP real-time propagation delay monitoring.

(244) FIG. 120 is a graph illustrating test-packet propagation delay monitoring.

(245) FIG. 121 is a schematic diagram showing tri-channel SDNP meshed transport.

(246) FIG. 122 is a schematic diagram showing SDNP redundant name servers.

(247) FIG. 123 is a schematic diagram showing SDNP redundant signaling servers.

(248) FIG. 124A is a flow chart showing tri-channel SDNP communication, part 1.

(249) FIG. 124B is a flow chart showing tri-channel SDNP communication, part 2.

(250) FIG. 124C is a flow chart showing tri-channel SDNP communication, part 3.

(251) FIG. 124D is a flow chart showing tri-channel SDNP communication, part 4.

(252) FIG. 124E is a flow chart showing tri-channel SDNP communication, part 5.

(253) FIG. 125A is a flow chart summarizing an SDNP tri-channel packet sending sequence.

(254) FIG. 125B is a network map summarizing an SDNP tri-channel packet sending routing.

(255) FIG. 126A is a flow chart summarizing an SDNP tri-channel packet reply sequence.

(256) FIG. 126B is a network map summarizing an SDNP tri-channel packet reply routing.

(257) FIG. 126C is a flow chart summarizing an alternate embodiment of the SDNP tri-channel packet reply sequence.

(258) FIG. 127 is a schematic diagram showing SDNP node packet pre-processing.

(259) FIG. 128 is a schematic diagram showing SDNP re-packeting.

(260) FIG. 129A is a schematic diagram showing last-node real-time packet reconstruction.

(261) FIG. 129B is a schematic diagram showing buffered last node packet reconstruction.

(262) FIG. 129C is a schematic diagram showing buffered client packet reconstruction.

(263) FIG. 129D is a flow chart summarizing client packet construction.

(264) FIG. 130 is a schematic diagram showing SDNP command and control signal packets.

(265) FIG. 131 is a schematic diagram showing SDNP dynamic route discovery.

(266) FIG. 132A is a flow chart showing command and control signal packets, path 1-1.

(267) FIG. 132B is a flow chart showing command and control signal packets, path 1-2.

(268) FIG. 132C is a schematic diagram showing SDNP packet reconstruction.

(269) FIG. 133A is a schematic diagram showing an OSI-layer representation of SDNP fragmented transport.

(270) FIG. 133B is a schematic diagram showing an OSI-layer representation of tunneled SDNP fragmented transport.

(271) FIG. 134 is a schematic diagram showing SDNP packet race routing.

(272) FIG. 135 is a table comparing SDNP communication to other packet-switched network communication.

DESCRIPTION OF THE INVENTION

(273) After nearly one-and-a-half centuries of circuit-switched telephony, today's communication systems and networks have within only a decade all migrated to packet-switched communication using the Internet Protocol carried by Ethernet, WiFi, 4G/LTE, and DOCSIS3 data over cable and optical fiber. The benefits of commingling voice, text, pictures, video, and data are many, including the use of redundant paths to insure reliable IP packet delivery, i.e. the reason the Internet was created in the first place, along with an unparalleled level of system interoperability and connectivity across the globe. With any innovation, however, the magnitude of challenges new technology creates often match the benefits derived.

(274) Disadvantages of Existing Communication Providers

(275) As detailed throughout the background section of this disclosure, present-day communication suffers from many disadvantages. The highest performance communication systems today, comprising custom digital hardware owned by the world's major long-distance carriers such as AT&T, Verizon, NTT, Vodaphone, etc., generally offer superior voice quality but at a high cost including expensive monthly subscription fees, connection fees, long-distance fees, complex data rate plans, long-distance roaming charges, and numerous service fees. Because these networks are private, the actual data security is not publically known, and security infractions, hacks, and break-ins are generally not reported to the public. Given the number of wire taps and privacy invasions reported in the press today, private carrier communication security remains suspect, if not in their private cloud, in the very least in their last-mile connections.

(276) Internet service providers or ISPs form another link in the global chain of communications. As described in the background of this invention, voice carried over the Internet using VoIP, or voice over Internet protocol suffers from numerous quality-of-service or QoS problems, including The Internet, a packet-switched network, is not designed to deliver IP packets in a timely manner or to support real-time applications with low latency and high QoS The routing of an IP packet takes an unpredictable path resulting in constantly changing delays, bursts of high data-error rates, and unexpected dropped calls IP packet routing is made at the discretion of the Internet service provider, which controls the network within which the packet is routed and may adjust routing for balancing its own network's loading or to better serve its VIP clients at the expense at degrading connection quality of general traffic traversing its network. Over-the-top or OTT providers such as Line, KakaoTalk, Viber, etc. catching a free ride on the Internet act as Internet hitchhikers and have no control over the network or factors affecting QoS. Using heavyweight audio CODECs that fail to provide comprehendible voice quality audio even at moderate data rates VoIP based on the TCP transport protocol suffers from high latency and degraded audio caused by delays induced during handshaking and IP packet rebroadcasting. Unaided UDP transport provides no guarantee of payload integrity.

(277) Aside from QoS issues, the security of today's devices and networks is abysmal, representing a level totally unacceptable to support the future needs of global communication. As detailed in the background and shown previously in FIG. 40, network security is prone to a large array of cyber-assaults on communicating devices, including spyware, Trojan horses, infections, and phishing; on the last link, including spyware, IP packet sniffing, wiretaps, and call interception of cyber pirate faux cellphone towers; and in the local network or telco portion of last-mile connectivity, involving spyware, IP packet sniffing, infections such as viruses, and cyber pirate man in the middle attacks. The cloud itself is subject to unauthorized access by breaking security at any cloud gateway, by infections such as viruses, from cyber pirates launching man-in-the-middle attacks, from denial-of-service attacks, and from unauthorized government surveillance. In summary, today's communication security is compromised by numerous vulnerabilities easily exploited by cyber pirates and useful for committing cybercrime and violations of cyberprivacy, including: Revealing the destination of an IP packet, including the destination IP address, the destination port #, and the destination MAC address. Revealing the source of an IP packet, including the source IP address, the source port #, and the source MAC address. Revealing the type of Layer 4 transport employed and by the port # the type of service requested and application data encapsulated in the IP packet's payload In unencrypted files, all application and file data encapsulated in the IP packet's payload, including personal and confidential information, login information, application passwords, financial records, videos, and photographs. A dialog of communications, enabling a cyber party the repeated opportunity to break encrypted files Numerous opportunities to install malware, including spyware and phishing programs and Trojan horses into communicating devices and routers using FTP, email, and web page based infections

(278) Reiterating a key point, the fundamentally intrinsic weakness of packet-switched communication networks using Internet Protocol shown in FIG. 44, is that any hostile party or cyber pirate intercepting IP packet 670 can see what devices were involved in creating the data contained with the IP packet, where the IP packet came from, where the IP packet is being sent to, how the data is being transported, i.e. UDP or TCP, and what kind of service is being requested, i.e. what kind of application data is contained within the payload. In this regard, a cyber pirate is able to determine the context of a conversation, improving their opportunity to crack encryption, break password security, and gain unauthorized access to files, data, and payload content.

(279) Encryption

(280) To defend against the diverse range of cyber-assaults as described, present day network managers, IT professionals, and application programs primarily rely on a single defenseencryption. Encryption is a means by which to convert recognizable content also known as plaintext, whether readable text, executable programs, viewable videos and pictures, or intelligible audio, into an alternate file type known as ciphertext, that appears as a string of meaningless textual characters.

(281) The encryption process, converting an unprotected file into an encrypted file, involves using a logical or mathematical algorithm, called a cypher, to change the data into equivalent textual elements without revealing any apparent pattern of the encryption's conversion process. The encrypted file is then sent across the communication network or medium until received by the destination device. Upon receiving the file, the receiving device, using a process known as decryption, subsequently decodes the encoded message to reveal to original content. The study of encryption and decryption, known broadly as cryptography, blends elements of mathematics, including number theory, set theory and algorithm design, with computer science and electrical engineering.

(282) In simple single key or symmetric key encryption technologies, a single key word or phrase known a priori by both parties can be used to unlock the process for encrypting and decrypting a file. In World War II, for example, submarines and ocean ships communicated on open radio channels used encrypted messages. Initially, the encryptions were single-key-based. By analyzing the code pattern, Allied cryptologists were sometimes able to reveal the encryption key word or pattern and thereafter were able to read encrypted files without discovery. As encryption methods became more complex, breaking the code manually became more difficult.

(283) Code evolved into mechanical machine-based ciphers, an early form of computing. At the time, the only way to break the code was stealing a cypher machine and using the same tools to decipher a message as those encrypting the files. The challenge was how to steal a cypher machine without the theft being detected. If it were known that a code machine had been compromised, the enemy would simply change their code and update their cypher machines already in operation. This principle is practiced still todaythe most effective cyber-assault is one that goes undetected.

(284) With the advent of computing and the Cold War, encryption became more complex but the speed of computers used to crack encryption codes also improved. At each step in the development of secure communications, the technology and knowhow for encrypting information and the ability to crack the encryption code developed nearly at pace. The major next evolutionary step in encryption came in the 1970s with the innovation of dual-key encryption, a principle still in use today. One of the best-known dual key encryption methods is the RSA public key cryptosystem, named after its developers Rivest, Shamir, and Adleman. Despite published recognition for RSA, contemporaneous developers independently conceived of the same principle. RSA employs two cryptographic keys based on two large prime numbers kept secret from the public. One algorithm is used to convert these two prime numbers into an encryption key, herein referred to as an E-key, and a different mathematical algorithm is used to convert the same two secret prime numbers into a secret decryption key, herein referred to also as a D-key. The RSA-user who selected the secret prime numbers, herein referred to as the key publisher, distributes or publishes this algorithmically generated E-key comprising typically between 1024 b to 4096 b in size, to anyone wishing to encrypt a file. Because this key is possibly distributed to many parties in an unencrypted form, the E-key is known as a public key.

(285) Parties wishing to communicate with the key publisher then use this public E-key in conjunction with a publically available algorithm, typically offered in the form of commercial software, to encrypt any file to be sent to the particular key publisher. Upon receiving an encrypted file, the key publisher then uses their secret D-key to decrypt the file, returning it to plaintext. The unique feature of the dual-key method in general and RSA algorithm in particular is that the public E-key used to encrypt a file cannot be used for decryption. Only the secret D-key possessed by the key publisher has the capability of file decryption.

(286) The concept of a dual-key, split-key, or multi-key exchange in file encryption and decryption is not limited specifically to RSA or any one algorithmic method, but methodologically specifies a communication method as a sequence of steps. FIG. 47, for example, illustrates a dual-key exchange in realizing communication over a switch packet communication network. As shown, notebook 35 wishing to receive a secure file from cell phone 32 first generates two keys, E-key 690 for encryption and D-key 691 for decryption using some algorithm. Notebook 35 then sends E-key 690 to cell phone 32 using public network communication 692 carrying IP packet 695. IP packet 695 clearly illustrates in unencrypted form, the MAC address, IP source address NB and port address #9999 of notebook 35 along with the destination IP address CP, port #21 of cell phone 32 as well as the transport protocol TCP and an encrypted copy of E-key 690 as its payload.

(287) Using an agreed upon encryption algorithm or software package, cell phone 32 then processes plaintext file 697A using encryption algorithm 694A and encryption E-key 690 to produce an encrypted file, i.e. ciphertext 698, carried as the payload of IP packet 696 in secure communication 693 from cell phone 32 to notebook 35. Upon receiving IP packet 696, algorithm 694B decrypts the file using secret decryption key, i.e. D-key 691. Since D-key 691 is made consistent with E-key 690, in essence algorithm 694B employs knowledge of both keys to decrypt ciphertext 698 back into unencrypted plaintext 697B. While the payload of IP packet 696 is secured in the form of an encrypted file, i.e. ciphertext 698, the rest of the IP packet is still unencrypted, sniffable, and readable by any cyber pirate including the source IP address CP and port #20, and the destination IP address NB and associated port #9999. So even if the payload itself can't be opened, the communication can be monitored.

(288) Virtual Private Networks

(289) Another security method, also relying on encryption, is that of a virtual private network or VPN. In a VPN, a tunnel or secure pipe is formed in a network using encrypted IP packets. Rather than only encrypting the payload, in a VPN the entire IP packet is encrypted and then encapsulated into another unencrypted IP packet acting as a mule or carrier transmitting the encapsulated packet from one VPN gateway to another. Originally, VPNs were used to connect disparate local area networks together over a long distance, e.g. when companies operating private networks in New York. Los Angeles, and Tokyo wished to interconnect their various LANs with the same functionality as if they shared one global private network.

(290) The basic VPN concept is illustrated in FIG. 48A where server 700, as part of one LAN supporting a number of devices wirelessly through RF connections 704 and wireline connections 701 is connected by a virtual private network or VPN comprising content 706 and VPN tunnel 705 to a second server 707 having wireline connections 708 to desktops 709A thru 709C, to notebook 711, and to WiFi base station 710. In addition to these relatively low bandwidth links, server 707 also connects to supercomputer 713 via high bandwidth connection 712. In operation, outer IP packet 714 from server A, specifying a source IP address S8 and port #500 is sent to server B at destination IP address S9 and port #500. This outer IP packet 714 describes how servers 700 and 707 form an encrypted tunnel to one another for data to pass within. The VPN payload of outer packet 714 contains last-mile IP packet 715, providing direct communication between desktop 702B with source IP address DT and corresponding ad hoc port #17001, and notebook 711 with source IP address NB and corresponding ad hoc port #21, a request for a file transfer.

(291) To establish this transfer securely using a virtual private network, VPN tunnel 705 was created and the session initiated before the actual communication was sent. In corporate applications, the VPN tunnel 705 is not carried over the Internet on an ad hoc basis, but is generally carried by a dedicated ISP or carrier owning their own fiber and hardware network. This carrier oftentimes enters into an annual or long-term contractual agreement with the company requiring VPN services to guarantee a specific amount of bandwidth for a given cost. Ideally, the high-speed dedicated link connects directly to both server 700 and server 707 with no intermediate or last-mile connections to disturb the VPN's performance, QoS, or security.

(292) In operation, traditional VPNs require a two-step processone to create or login to the VPN, and a second step to transfer data within the secure pipe or tunnel. The concept of tunneling is illustrated hierarchically in FIG. 48B where outer IP packets carried by communication stacks 720 and 721 form a VPN connection 722 on Layers 1 through Layers 4, utilize Layer 5 to create a virtual VP session 723, and utilize Layer 6, the presentation layer, to facilitate encryption 725 to achieve VPN gateway to gateway pipe 705 between server 700 and 707. While VPN connection 722 uses Internet Protocol to send the IP packets, the VPN's PHY Layer 1 and VPN data link Layer 2 are generally supported by a dedicated carrier and not using unpredictable routing over the Internet. Application Layer 6 data transferred as device-to-device communication 706 between desktop 702C and 709A for example, is supplied as tunneled data 726 including all seven OSI layers needed to establish communication as if the VPN were not present.

(293) In operation, outer IP packet from communication stack 720 once passed to server 707 is opened to reveal encapsulated data 726, the true message of the packet. In this way, the end-to-end communication occurs ignorant of the details used to create the VPN tunnel, except that the VPN tunnel must be formed in advance of any attempt to communicate and closed after the conversation is terminated. Failure to open the VPN tunnel first will result in the unencrypted transmission of IP packet 715 susceptible to IP packet sniffing, hijacking, infection and more. Failure to close the VPN after a conversation is complete, may provide a cybercriminal the opportunity to hide their illegal activity within someone else's VPN tunnel, and if intercepted, may result in possible criminal charges levied against an innocent person.

(294) While VPNs are common ways for multiple private local area networks to interconnect to one another using private connections with dedicated capacity and bandwidth, the use of VPNs over public Networks and the Internet is problematic for two party communications. One issue with VPNs is the VPN connection must be established a priori, before it can be used, not on a packet-by-packet basis. For example, as shown in exemplary FIG. 48C of a VoIP call connected over a packet-switched network, before cell phone 730 contacts the intended call recipient at cell phone 737, it must first establish a VPN session following steps 740 in the simplified algorithm as shown. In so doing cell phone 730 with a VPN connection application sends IP packets to VPN host 733 through any available last-mile routing, in this case radio communication 741A to WiFi base station 731, followed by wireline communication 741B to router 732, then by wireline communication 741C to VPN host 733. Once the session between cell phone 730 and VPN host 733 is established, cell phone 730 then instructs VPN host 733 to create a VPN tunnel 741 to VPN host 734, the Layer 5 session is negotiated with the tunnel encrypted by Layer 6.

(295) Once the VPN connection is set up, then cell phone 730 in accordance with application related steps 745 places a call via any VoIP phone app. In this step, the application must establish a call out link over the last mile from VPN host 734 to cell phone 737. If the VoIP application is unable or unauthorized to do so, the call will fail and immediately terminate. Otherwise, the inner IP packet will establish an application Layer 5 session between calling cell phone 730 and destination cell phone 737 and confirm the IP test packets are properly decrypted and intelligible.

(296) To place a call in accordance with step 745, the call necessarily comes from a Layer 7 application running on the phone and not from the phone's normal dialup functions, because the telephonic carrier's SIM card in the phone is not compatible with the VPN tunnel. Once the call is initiated, cell phone 730 transmits a succession of IP packets representing small pieces or snippets of sound in accordance with its communication application. In the example shown, these packets are sent from the application in caller's cell phone 730 through WiFi link 746A to WiFi base station 731 then through wireline connection 746B to router 732, and finally through wireline connection 746C to VPN host 733. The data is then sent securely by connection 747 to VPN host 735 through VPN tunnel 742. Once leaving the VPN tunnel, VPN host sends the data onward on wireline connection 748A to router 735, then by wireline connection 748B to cell phone system and tower 736 which in turn calls 737 as a normal phone call. The process of calling from a cell phone app to a phone not running the same app is called a call out feature.

(297) The foregoing example highlights another problem with connecting to a VPN over a public networkthe last-mile links from both the caller on cell phone 730 to VPN host 733 and the call out from VPN host 734 to the person being called on cell phone 737 are not part of the VPN, and therefore do not guarantee security, performance or call QoS. Specifically the caller's last mile comprising connections 746A, 746B, and 746C as well as the call out connections 748A, 748B, and 748C are all open to sniffing and subject to cyber-assaults.

(298) Once the call is completed and the cell phone 737 hangs up, VPN 742 must be terminated according to step 749 where VPN Layer 5 coordinates closing the VPN session and cell phone 730 disconnects from VPN host 733.

(299) Even following the prescribed steps, however, there is no guarantee that placing a call or sending documents through a VPN may not fail for any number of reasons including: The VPN may not operate with sufficient low latency to support real-time applications, VoIP or video; The VPN last-mile connection from the caller to the VPN gateway or from the VPN gateway to the call recipient may not operate with sufficient low latency to support real-time applications, VoIP or video; The nearest VPN gateway to the caller or to the intended recipient, i.e. the last mile may be very far away, possibly even farther than the distance to the call recipient without the VPN, exposing the connection to excessive latency, network instability, uncontrolled routing through unknown networks, variable QoS, and numerous opportunities for man-in-middle attacks in the unprotected portion of the connection; The VPN last-mile connection from the VPN gateway to the call recipient may not support call out connections and packet forwarding or support links to local telcos; Local carriers or government censors may block calls or connections into or out of known VPN gateways for reasons of national security or regulatory compliance; Using corporate VPNs, VoIP calls may limited to and from only company employees and specified authorized users, financial transactions and video streaming may be blocked, private email to public email servers such Yahoo, Google, etc. may be blocked, and numerous web sites such YouTube, chat programs, or Twitter may be blocked as per company policy. In cases of unstable networks, a VPN may get stuck open and retain a permanent session connected to a caller's device until manually reset by the VPN operator. This can lead to lost bandwidth for subsequent connections or expensive connection fees.

(300) Comparing Networks

(301) Comparing communication offered by over-the top or OTT providers, shown in FIG. 49A, to that of communication systems employing public networks to connect to an ad hoc VPN, shown previously in FIG. 48C, quickly reveals that aside from the VPN link itself, the majority of both communication systems have nearly identical components and connections. Specifically, the last mile of the caller comprising cell phone 730, WiFi radio connection 746A, WiFi base station 731, wireline connections 746B and 746C, and router 732 represent the same last-mile connectivity in both implementations. Similarly, on the last mile of the other party, cell phone 737, cell phone connection 748C, cell base station and tower 736, wireline connections 748A and 748B, and router 735 are identical for both Internet and VPN versions. The main difference is that in a public network, the VPN tunnel 742 with secure communication 747 between VPN hosts 733 and 734 is replaced by server/routers 752 and 754 carrying insecure communication connection 755. Another difference is in OTT communications, the call is instantly available as described in step 750, where using a VPN extra steps 740 and 749 are required to set up the VPN and to terminate the VPN session prior to and following the call.

(302) In both examples, the last-mile connections offer unpredictable call QoS, exposure to packet sniffing, and the risk of cyber-assaults. Because server/routers 752 and 774 are likely managed by different ISPs in different locales, one can interpret the servers as existing different clouds, i.e. clouds 751 and 753. For example the publically open networks owned and operated by Google, Yahoo, Amazon, and Microsoft may be considered as different clouds, e.g. the Amazon cloud even though they are all interlinked by the Internet.

(303) A competing network topology, the peer-to-peer network or PPN shown in FIG. 49B, comprising a network made of a large number of peers with packet routing managed by the PPN and not by the router or ISP. While peer-to-peer networks existed in hardware for decades, it was Napster who popularized the concept as a means to avoid the control, costs, and regulation of Internet service providers. When sued by the U.S. government regulators for music copyright violations, the progenitors of Napster jumped ship, invading the early OTT carrier Skype. At that time, Skype's network converted from a traditional OTT into a Napster-like PPN.

(304) In PPN operation, every device that makes a login connection to the PPN becomes one more node in the PPN. For example if in geography 761, cell phone 730 with PPN software installed logs into the peer-to-peer network, it like all the other connected devices in the region becomes part of the network. Calls placed by any devices hops around from one device to another to reach is destination, another PPN connected device. For example, if cell phone 730 uses its PPN connection to call another PPN connected device, e.g. cell phone 768, the call follows a circuitous path through any device(s) physically located in the PPN between the two parties. As shown, the call emanating from cell phone 730 connects by WiFi 731 through WiFi base station 731 to desktop 765A, then to notebook 766A, to desktop 765B, then to desktop 765C and finally to cell phone 768 through cell phone base station and tower 767. In this manner all routing was controlled by the PPN and the Internet was not involved in managing the routing. Since both parties utilize, the PPN software used to connect to the network also acts as the application for VoIP based voice communication.

(305) In the case where cell phone 730 attempts to call a non-PPN device cell phone on the opposite side of the world, the routing may necessarily include the Internet on some links, especially to send packets across oceans or mountain ranges. The first part of the routing in geography 761, proceeds in a manner similar to the prior example, starting from cell phone 730 and routed through WiFi base station 731, desktop 765A, notebook 766A, desktops 765B and 765C. At this point, if notebook 766B is connected to the network, the call will be routed through it, otherwise the call must be routed through cell phone base station and tower 767 to cell phone 768, and then back to cell phone base station and tower 767 before sending it onwards.

(306) If the call is transpacific, then computers and cell phones cannot carry the traffic across the ocean so the call is then necessarily routed up to the Internet to 3.sup.rd party server/router 770 in cloud 763 and onward through connection 747 to 3.sup.rd a party server/router 771 in cloud 764. The call then leaves the Internet and enters the PPN in geography 762 first through desktop 772, which in turn connects to WiFi 773, to notebook 776, and to base station 736. Since WiFi 733 does not run the PPN app, the actual packet entering WiFi 773 must travel to either tablet 775 or cell phone 774 and back to WiFi 773 before being sent on to cell phone base station and tower 736 via a wireline connection. Finally, cell phone call 748C connects to cell phone 737, which is not a PPN enabled device. The connection thereby constitutes a call out for the PPN because it exits PPN geography 762. Using this PPN approach, like a VPN involves first registering a calling device to the PPN network according to step 760 by completing a PPN login. Thereafter, the call can be placed using the PPN app in accordance with step 769. The advantage of the PPN approach is little or no hardware is needed to carry a call over a long distance, and that since every device connected to the PPN regularly updates the PPN operator as to its status, loading and latency, the PPN operator can decide a packet's routing to best minimize delay.

(307) The disadvantages of such an approach is that packets traverse a network comprising many unknown nodes representing a potential security threat and having an unpredictable impact on call latency and call QoS. As such, except for Skype, peer-to-peer networks operating at Layer 3 and higher are not commonly employed in packet-switched communication networks.

(308) A comparative summary of ad hoc VPN providers, Internet OTT providers, and PPN peer networks is contrasted below.

(309) TABLE-US-00005 Network Virtual Private VPN Internet OTT Peer-to-Peer PPN Nodes Public/Hosted Servers Public PPN Users Routers/Servers Node Capability Known Infrastructure Known Mixed, Unknown Infrastructure Cloud Bandwidth Guaranteed Unpredictable Unpredictable Last-Mile Provider Dependent Provider PPN Dependent Bandwidth Dependent Latency Unmanageable Unmanageable Best Effort Network Stability Unmanageable Unmanageable, Best Effort Redundant Call Setup Complex Login None Required Login User Identity User Name Phone Number User Name VoIP QoS Variable to Good Variable Variable Cloud Security Encrypted Payload Only Unencrypted Unencrypted Last-Mile Security Unencrypted Unencrypted Unencrypted Sniffable Packet Header (Cloud) Entire Packet Entire Packet Entire Packet (Last Mile)

(310) As shown, while VPN and the Internet comprise fixed infrastructure, the nodes of a peer-to-peer network vary depending on who is logged in and what devices are connected to the PPN. The cloud bandwidth, defined in the context of this table as the networks' high-speed long-distance connections, e.g. networks crossing oceans and mountain ranges, is contractually guaranteed only in the case of VPNs, and is otherwise unpredictable. The last-mile bandwidth is local provider dependent for both Internet and VPN providers but for PPN is entirely dependent on who is logged in.

(311) Latency, the propagation delay of successively sent IP packets is unmanageable for OTTs and VPNs because the provider does not control routing in the last mile but instead depends on local telco or network providers, while PPNs have limited ability using best efforts to direct traffic among the nodes that happen to be online at the time in a particular geography. Likewise, for network stability, PPNs have the ability to reroute traffic to keep a network up but depend entirely on who is logged in. The Internet, on the other hand, is intrinsically redundant and almost certain to guarantee delivery but not necessarily in a timely manner. Network stability for an ad hoc VPN depends on the number of nodes authorized to connect to the VPN host. If these nodes go offline, the VPN is crippled.

(312) From a call setup point of view the Internet is always available, PPNs require the extra step of logging into the PPN prior to making a call, and VPNs can involve a complex login procedure. Moreover, most users consider OTT's use of phone numbers rather than separate login IDs used by VPNs and PPNs as a major beneficial feature in ease of use. All three networks listed suffer from variable VoIP QoS, generally lagging far behind commercial telephony carriers.

(313) From a security point of view, all three options are bad with the last mile completely exposed to packet sniffing with readable addresses and payloads. VPNs offer encryption of the cloud connection but still expose the IP addresses of the VPN hosts. As such no network option shown is considered secure. As such, encryption is used by various applications to try to prevent hacking and cyber-assaults, either as a Layer 6 protocol or as an embedded portion of the Layer 7 application itself.

(314) Overreliance on Encryption

(315) Regardless of whether used for encrypting IP packets or establishing VPNs, today's network security relies almost solely on encryption and represents one weakness in modern packet-switched based communication networks. For example, numerous studies have been performed on methods to attack RSA encryption. While limiting the prime numbers to large sizes greatly reduces the risk of breaking the decryption D-key code using brute force methods, polynomial factor methods have been successfully demonstrated to crack keys based on smaller prime number-based keys. Concerns exist that the evolution of quantum computing will ultimately lead to practical methods of breaking RSA-based and other encryption keys in reasonable cyber-assault times.

(316) To combat the ever-present risk of code breaking, new algorithms and bigger key encryption methods such as the advanced encryption standard or AES cipher adopted by US NIST in 2001 have emerged. Based on the Rijndael cipher, the design principle known as a substitution-permutation network combines both character substitution and permutation using different key and block sizes. In its present incarnation, the algorithm comprises fixed block sizes of 128 bits with keys comprising varying lengths of 128 bits, 192 bits, and 256 bits, with the corresponding number of repetitions used in the input file transformation varying in rounds of 10, 12, and 14 cycles respectively. As a practical matter, AES cipher may be efficiently and rapidly executed in either software or hardware for any size of key. In cryptography vernacular, an AES based encryption using a 256 b key is referred to as AES256 encryption. AES512 encryption employing a 512 b key is also available.

(317) While each new generation raises the bar in cryptography to make better encryption methods and to more quickly break them, profit-minded cybercriminals often concentrate on their targets rather than simply using computing to break an encrypted file. As described previously, using packet sniffing and port interrogation, a cyber pirate can gain valuable information about a conversation, a corporate server, or even a VPN gateway. By cyber-profiling, it may be easier to launch a cyber-assault on a company's CFO or CEO's personal computers, notebooks, and cell phones rather than attack the network itself. Sending emails to employees that automatically install malware and spyware upon opening an embedded link completely circumvent firewall security because they enter the network from inside where employees necessarily must connect and work.

(318) The chance of breaking encryption also improves if data moves through a network without changing, i.e. statically. In the network of FIG. 50, for example, the underlying data in packets 790, 792, 794 and 799 remain unchanged as the packets move through the network. Each data packet shown comprises a sequence of data or sound arranged sequentially in time or pages unaltered from its original order when it was created. If the content of a data packet is textual, reading the unencrypted plaintext file in the sequence 1A-1B-1C-1D-1E-1F will result in legible text for communiqu? number 1. If the content of a data packet is audio, converting, i.e. playing, the unencrypted plaintext file in the sequence 1A-1B-1C-1D-1E-1F through a corresponding audio CODEC, essentially a software based D/A converter, will result in sound for audio file number 1.

(319) In either case, throughout this disclosure, each data slot represented by fixed size boxes comprises a prescribed number of bits, e.g. two bytes (2 B) long. The exact number of bits per slot is flexible just so long as every communication node in a network knows what the size of each data slot is. Contained within each data slot is audio, video, or textual data, identified in the drawings as a number followed by a letter. For example, as shown, the first slot of data packet 790 contains the content 1A where the number 1 indicates the specific communication #1 and the letter A represents the first piece of the data in communication #1. Similarly, the second slot of data packet 790 contains the content 1B where the number 1 indicates it is part of the same communication #1 and the letter B represents the second piece of the data in communication #1, sequentially following 1A.

(320) If, for example, the same data packet hypothetically included content 2A the data represents the first packet A in a different communication, specifically for communication #2, unrelated to communication #1. Data packets containing homogeneous communications, e.g. where all the data is for communication #1 are easier to analyze and read than those mixing different communications. Data arranged sequentially in proper order makes it easy for a cyber-attacker to interpret the nature of the data, whether it is audio, text, graphics, photos, video, executable code, etc.

(321) Moreover, in the example shown, since the packet's source and destination IP addresses remain constant, i.e. where the packets remain unchanged during transport through the network in the same form as the data entering or exiting gateway servers 21A and 21F, because the underlying data doesn't change, a hacker has more chances to intercept the data packets and a better chance to analyze and open the files or listen to the conversation. The simple transport and one-dimensional security, i.e. relying only on encryption for protection, increases the risk of a cyber-attack because the likelihood of success is higher in such overly simplified use of the Internet as a packet-switched network.

(322) Securine Real-Time Networks and Connected Devices

(323) In order to improve the quality of service (QoS) of telephonic, video, and data communication while addressing the plethora of security vulnerabilities plaguing today's packet-switched networks, a new and innovative systemic approach to controlling IP packet routing is required, one that manages a global network comprising disparate technologies and concurrently facilitates end-to-end security. The goals of such an inventive packet-switched network include the following criteria: 1. Insure the security and QoS of a global network or long-distance carrier including dynamically managing real-time voice, video, and data traffic routing throughout a network; 2. Insure the security and QoS of the local network or telco in the last mile of the communication network; 3. Insure the security and QoS of the last link of the communication network, including providing secure communication over unsecured lines; 4. Insure the security of communicating devices and authenticate users to prevent unauthorized or fraudulent access or use; 5. Facilitate a secure means to store data in a device or online in network or cloud storage to prevent unauthorized access; 6. Provide security and privacy protection of all non-public personal information including all financial, personal, medical, and biometric data and records; 7. Provide security and privacy protection of all financial transactions involving online banking and shopping, credit cards, and e-pay; and 8. Provide security, privacy, and as-required, anonymity, in transactional and information exchange involving machine-to-machine (M2M), vehicle-to-vehicle (V2V), and vehicle-to-infrastructure (V2X) communication.

(324) Of the above stated goals, the inventive matter contained within this disclosure relates to the first topic described in item #1, i.e. to insure the security and QoS of a global network or long-distance carrier including dynamically managing real-time voice, video, and data traffic routing throughout a network. This topic can be considered as achieving network or cloud security without sacrificing real-time communication performance.

Glossary

(325) Unless the context requires otherwise, the terms used in the description of the Secure Dynamic Network And Protocol have the following meanings:

(326) Anonymous Data Packets: Data packets lacking information as to their original origin or final destination.

(327) Decryption: A mathematical operation used to convert data packets from ciphertext into plaintext.

(328) DMZ Server: A computer server not accessible directly from the SDNP network or the Internet used for storing selectors, seed generators, key generators and other shared secrets.

(329) Dynamic Encryption/Decryption: Encryption and decryption relying on keys that change dynamically as a data packet traverses the SDNP network.

(330) Dynamic Mixing: The process of mixing where the mixing algorithms (the inverse of splitting algorithms) change dynamically as a function of a seed based on a state, such as the time, state, and zone when a mixed data packet is created.

(331) Dynamic Scrambling/Unscrambling: Scrambling and unscrambling relying on algorithms that change dynamically as a function of a state, such as the time when a data packet is created or the zone in which it is created.

(332) Dynamic Splitting: The process of splitting where the splitting algorithms change dynamically as a function of a seed based on a state, such as the time, state, and zone when a data packet is split into multiple sub-packets.

(333) Encryption: A mathematical operation used to convert data packets from plaintext into ciphertext.

(334) Fragmented Data Transport: The routing of split and mixed data through the SDNP network.

(335) Junk Data Deletions (or De-junking): The removal of junk data from data packets in order to restore the original data or to recover the data packet's original length.

(336) Junk Data Insertions (or Junking): The intentional introduction of meaningless data into a data packet, either for purposes of obfuscating the real data content or for managing the length of a data packet.

(337) Key: A disguised digital value that is generated by inputting a state, such as time, into a key generator which uses a secret algorithm to generate the key. A key is used to select an algorithm for encrypting the data in a packet from a selector. A key can be used to safely pass information regarding a state over public or unsecure lines.

(338) Key Exchange Server: A computer server, often third party hosted and independent of the SDNP network operator, used to distribute public encryption keys to clients, and optionally to servers using symmetric key encryption, especially for client-administered key management, i.e. client based end-to-end encryption to prevent any possibility of network operator spying.

(339) Last Link: The network connection between a Client's device and the first device in the network with which it communicates, typically a radio tower, a WiFi router, a cable modem, a set top box, or an Ethernet connection.

(340) Last Mile: The network connection between a SDNP Gateway and the Client, including the Last Link.

(341) Mixing: The combining of data from different sources and data types to produce one long data packet (or a series of smaller sub-packets) having unrecognizable content. In some cases previously split data packets are mixed to recover the original data content. The mixing operation may also include junk data insertions and deletions and parsing.

(342) Parsing: A numerical operation whereby a data packet is broken into shorter sub-packets for storage or for transmission.

(343) Scrambling: An operation wherein the order or sequence of data segments in a data packet is changed from its natural order into an unrecognizable form.

(344) Splitting: An operation wherein a data packet (or a sequence of serial data packets) is split into multiple sub-packets which are routed to multiple destinations. A splitting operation may also include junk data insertions and deletions.

(345) SoftSwitch: Software comprising executable code performing the function of a telecommunication switch and router.

(346) SDNP: An acronym for secure dynamic network and protocol meaning a hyper-secure communications network made in accordance with this invention.

(347) SDNP Administration Server: A computer server used to distribute executable code and shared secrets to SDNP servers globally or in specific zones.

(348) SDNP Bridge Node: A SDNP node connecting one SDNP Cloud to another having dissimilar Zones and security credentials.

(349) SDNP Client or Client Device: A network connected device, typically a cell phone, tablet, notebook, desktop, or IoT device running a SDNP application in order to connect to the SDNP Cloud, generally connecting over the network's last mile.

(350) SDNP Cloud: A network of interconnected SDNP Servers running SoftSwitch executable code to perform SDNP Communications Node operations.

(351) SDNP Gateway Node: A SDNP node connecting the SDNP Cloud to the SDNP Last Mile and to the Client. SDNP Gateway nodes require access to at least two Zonesthat of the SDNP Cloud and of the Last Mile.

(352) SDNP Media Node: SoftSwitch executable code that processes incoming data packets with particular identifying tags in accordance with instructions from the signaling server or another computer performing the signaling function, including encryption/decryption, scrambling/unscrambling, mixing/splitting, tagging and SDNP header and sub-header generation. An SDNP Media Node is responsible for identifying incoming data packets having specific tags and for forwarding newly generated data packets to their next destination.

(353) SDNP Media Server: A computer server hosting a SoftSwitch performing the functions of a SDNP Media Node in dual-channel and tri-channel communications and also performing the tasks of a SDNP Signaling Node and a SDNP Name-Server Node in single-channel communications.

(354) SDNP Name Server: A computer server hosting a SoftSwitch performing the functions of a SDNP Name-Server Node in tri-channel communications.

(355) SDNP Name Server Node: SoftSwitch executable code that manages a dynamic list of every SDNP device connected to the SDNP cloud.

(356) SDNP Network: The entire hyper-secure communication network extending from client-to-client including last link and last mile communication, as well as the SDNP cloud.

(357) SDNP Node: A SDNP communication node comprising a software-based SoftSwitch running on a computer server or alternatively a hardware device connected to the SDNP network, functioning as an SDNP node, either as Media Node, a Signaling Node, or a Name Server Node.

(358) SDNP Server: A computer server comprising either a SDNP Media Server, a SDNP Signaling Server, or a SDNP Name Server and hosting the applicable SoftSwitch functions to operate as an SDNP node.

(359) SDNP Signaling Node: SoftSwitch executable code that initiates a call or communication between or among parties, determines all or portions of the multiple routes for fragmented data transport based on caller criteria and a dynamic table of node-to-node propagation delays, and instructing the SDNP media how to manage the incoming and outgoing data packets.

(360) SDNP Signaling Server: A computer server hosting a SoftSwitch performing the functions of a SDNP Signaling Node in dual-channel and tri-channel SDNP communications, and also performing the duties of the SDNP Name-Sever Node in dual-channel communications.

(361) Security Settings: Digital values, such as seeds and keys, that are generated by seed generators or key generators using secret algorithms in conjunction with a constantly changing input state, such as network time, and that can therefore be safety transmitted over public or insecure lines.

(362) Seed: A disguised digital value that is generated by inputting a state, such as time, into a seed generator which uses a secret algorithm to generate the seed. A seed is used to select an algorithm for scrambling or splitting the data in a packet from a selector. A seed can be used to safely pass information regarding a state over public or unsecure lines.

(363) Selector: A list or table of possible scrambling, encryption or splitting algorithms that are part of the shared secrets and that are used in conjunction with a seed or key to select a particular algorithm for scrambling, unscrambling, encrypting, decrypting, splitting or mixing a packet or packets.

(364) Shared Secrets: Confidential information regarding SDNP node operation, including tables or selectors of scrambling/unscrambling, encryption/decryption, and mixing/splitting algorithms, as well as the algorithms used by seed generators, key generators, zone information, and algorithm shuffling processes stored locally on DMZ servers not accessible over the SDNP network or the Internet.

(365) State: An input, such as location, zone, or network time that is used to dynamically generate security settings such as seeds or keys or to select algorithms for specific SDNP operations such as mixing, splitting, scrambling, and encryption.

(366) Time: The universal network time used to synchronize communication across the SDNP network

(367) Unscrambling: A process used to restore the data segments in a scrambled data packet to their original order or sequence. Unscrambling is the inverse function of scrambling.

(368) Zone: A network of specific interconnected servers sharing common security credentials and shared secrets. Last mile connections comprise separate zones from those in the SDNP Cloud.

(369) Secure Dynamic Communication Network and Protocol (SDNP) Design

(370) To prevent cyber-assaults and hacking of packet-switched communication while minimizing real-time packet latency, insuring stable call connectivity, and delivering the highest integrity of voice communication and video streaming, the disclosed secure dynamic network and protocol, or SDNP, is designed based upon a number of guiding principles including: Real-time communication should always occur using the lowest latency path. Unauthorized inspection or sniffing of a data packet should provide no context as to where the packet came from, where it is going, or what is in it. Data packet payloads should be dynamically re-encrypted, i.e., decrypted and then encrypted again using a different encryption algorithm, with no risk of being hacked in any reasonable time. Even after they have been decrypted, all data packet payloads still contain incomprehensible payloads comprising a dynamically scrambled mix of multiple conversations and unrelated data mixed with junk packet fillers.
Implementation of the above guidelines involves a variety of unique and inventive methods, functions, features and implementations including in various embodiments some or all of the following The SDNP employs one or more dedicated clouds comprising telco, i.e. telecommunication system, soft-switch functions realized using proprietary command and control software not accessible through the Internet. All intra-cloud communication occurs using dedicated SDNP packet-routing within proprietary clouds based on SDNP addresses and dynamic ports (i.e. proprietary NAT addresses), not on IP addresses. SDNP addresses are not usable or routable over the Internet or outside the SDNP cloud. The SDNP network constantly identifies and dynamically routes all real-time communication through the lowest latency paths available. No secure or real-time communication is routed outside the SDNP cloud or over the Internet except in cloud-to-cloud and last-mile communication, and then generally using single-hop routing with invisible addresses. Routing data contained within a data packet identifies the routing for a single hop between two adjacent devices, identifying only the last and next server's SDNP or IP addresses The phone number or IP addresses of the caller and the call recipient, i.e. the clients' respective source and destination addresses, are not present in the IP packet headers nor is it present in the encrypted payload Command and control related shared secrets exist in system software installed in secure DMZ servers not accessible through the Internet. SDNP packet communication may occur through three independent channelsa name server used to identify elements within the SDNP cloud, media servers used for routing content and data, and signaling servers used for packet and call command and control. Routing information, along with keys and numeric seeds (as needed) are supplied to all participating media servers through an independent signaling channel prior to the call or communiqu? and not with content. The signaling server supplies the media servers with only the last and next destination of a packet traversing the network. Media packets contain fragmented data representing only a portion of a call, document, text or file, dynamically mixed and remixed with other packets containing fragmented data from other sources and of different types. Special security methods are employed to protect the first- and last-mile communication, including separating signaling server-related communications from media and content-related packets. Packet transport is content-type dependent, with voice and real-time video or streaming based on an enhanced UDP, while signaling packets, command-and-control packets, data files, application files, systems files, and other files which are sensitive to packet loss or latency utilize TCP transport. Special security and authentication methods are used to confirm that a device is the real client and not a clone, and to authenticate that the person communicating is the true owner of the device and not an imposter.

(371) To ensure secure communication with low latency and high QoS in VoIP and real-time applications, the disclosed secure dynamic network and protocol or SDNP, utilizes an inventive dynamic mesh network comprising Dynamic adaptive multipath and meshed routing with minimal latency Dynamic packet scrambling Dynamic fragmentation using packet splitting, mixing, parsing, and junk bit packet fillers Dynamic intra-node payload encryption throughout a network or cloud Dynamic network protocol with address disguising and need-to-know routing information Multichannel communication separating media and content from signaling, command and control, and network addresses Dynamic adaptive real-time transport protocol with data type specific features and contextual routing Support of client-encrypted payloads with user-key management Lightweight audio CODEC for high QoS in congested networks

(372) As described, SDNP communication relies on multi-route and meshed communication to dynamically route data packets. Contrasting single-path packet communication used for Internet OTT and VoIP communications, in SDNP communication in accordance with this invention, the content of data packets is not carried serially by coherent packets containing information from a common source or caller, but in fragmented form, dynamically mixing and remixing content emanating from multiple sources and callers, where said data agglomerates incomplete snippets of data, content, voice, video and files of dissimilar data types with junk data fillers. The advantage of the disclosed realization of data fragmentation and transport is that even unencrypted and unscrambled data packets are nearly impossible to interpret because they represent the combination of unrelated data and data types.

(373) By combining fragmented packet mixing and splitting with packet scrambling and dynamic encryption, these hybridized packets of dynamically encrypted, scrambled, fragmented data comprise meaningless packets of gibberish, completely unintelligible to any party or observer lacking the shared secrets, keys, numeric seeds, and time and state variables used to create, packet, and dynamically re-packet the data.

(374) Moreover, each packet's fragmented content, and the secrets used to create it, remain valid for only a fraction of a second before the packet is reconstituted with new fragments and new security provisions such as revised seeds, keys, algorithms, and secrets. The limited duration in which a cyber-pirate has available to break and open the state-dependent SDNP data packet further enhances SDNP security, requiring tens of thousands of compute years to be processed in one tenth of a second, a challenge twelve orders of magnitudes greater than the time available to break it.

(375) The combination of the aforementioned methods facilitates multi-dimensional security far beyond the security obtainable from static encryption. As such, the disclosed secure dynamic network and protocol is referred to herein as a hyper-secure network.

(376) Data Packet Scrambling

(377) In accordance with the disclosed invention, secure communication over a packet-switched network relies on several elements to prevent hacking and ensure security, one of which involves SDNP packet scrambling. SDNP packet scrambling involves rearranging the data segments out of sequence, rendering the information incomprehensible and useless. As shown in FIG. 51A an unscrambled data packet, data packet 923, processed through scrambling operation 924, results in scrambled data packet 925. The scrambling operation can use any algorithm, numerical method, or sequencing method. The algorithm may represent a static equation or include dynamic variables or numerical seeds based on states, such as time 920 when the scrambling occurred, and a numerical seed 929 generated by seed generator 921, which may generate seed 929 using an algorithm that is also dependent on a state such as time 920 at the time of the scrambling. For example, if each date is converted into a unique number ascending monotonically, then every seed 929 is unique. Time 920 and seed 929 may be used to select a specific algorithm and may also be used to select or calculate a specific scrambling operation 924, chosen from a list of available scrambling methods, i.e. from scrambling algorithms 922. In data flow diagrams, it is convenient to illustrate this packet-scrambling operation and sequence using a schematic or symbolic representation, as depicted herein by symbol 926.

(378) The unscrambling operation, shown in FIG. 51B illustrates the inverse function of scrambling operation 924, specifically unscrambling operation 927, where the state or time 920 and corresponding seed 929 used to create scrambled data packet 925 are re-used for undoing the scrambling to produce unscrambled data, specifically unscrambled data packet 923. Using the same state or time 920 employed when the packet scrambling first occurred, the same scrambling method must be used again in the unscrambling operation 927 as selected from scrambling algorithm list 922. Although scrambling algorithm list 922 references the term scrambling, the same algorithm table is used to identify and select the inverse function needed for performing unscrambling, i.e. scrambling algorithm list 922 contains the information needed both for scrambling data packets and for unscrambling data packets. Because the two functions involve the same steps performed in reverse order, list 922 could also be renamed as scrambling/unscrambling algorithms list 922. For clarity's sake however, the table is labeled only by the function and not by its anti-function.

(379) Should the scrambling algorithm selected for implementing unscrambling operation 927 not match the original algorithm employed in packet scrambling, or should seed 929 or state or time 920 not match the time scrambling occurred, then the unscrambling operation will fail to recover the original unscrambled data packet 923, and the packet data will be lost. In data flow diagrams, it is convenient to illustrate this packet unscrambling process and sequence using a schematic or symbolic representation, as depicted herein by symbol 928.

(380) In accordance with the disclosed invention, numerous algorithms may be used to perform the scrambling operation so long that the process is reversible, meaning repeating the steps in the opposite order as the original process returns each data segment to its original and proper location in a given data packet. Mathematically, acceptable scrambling algorithms are those that are reversible, i.e. where a function F(A) has an anti-function F.sup.?1(A) or alternatively a transform has a corresponding anti-function such that
F.sup.?1[F(A)]=A
meaning that a data file, sequence, character string, file or vector A processed by a function F will upon subsequent processing using the anti-function F.sup.?1 return the original input A undamaged in value or sequence.

(381) Examples of such reversible functions are illustrated by the static scrambling algorithms shown in FIG. 51C including mirroring and phase-shift algorithms. In mirroring algorithms the data segments are swapped with other data segments as a mirror image around a line of symmetry defined by the modulus or mod of the mirroring process. In mod-2 mirroring as shown, every two data segments of original input data packet 930 are swapped, i.e. where 1A and 1B are switched in position, as are 1C and 1D, 1E and 1F and so on, to produce scrambled output data packet 935, with a line of symmetry centered between the first and second data segments, between the third and fourth data segments, and so on, or mathematically as 1.5.sup.th, 3.5.sup.th, 5.5.sup.th, . . . , (1.5+2n).sup.th position.

(382) In mod-3 mirroring, the first and third data segments of every three data segments are swapped while the middle packet of each triplet remains in its original position. Accordingly, data segments 1A and 1C are swapped while 1 B remains in the center of the triplet, data segments 1D and 1F are swapped while 1E remains in the center of the triplet, and so on, to produce scrambled data packet output 936. In mod-3 mirroring, the line of symmetry is centered in the 2.sup.nd, 5.sup.th, 8.sup.th, . . . , (2+3n).sup.th position.

(383) In mod-4 mirroring, the first and fourth data segments and the second and third of every four data segments are swapped, and so on to produce scrambled output data packet 937 from input data packet 931. Accordingly, data segment 1A is swapped with 1D; data segment 1B is swapped with 1C; and so on. In mod-4 mirroring, the line of symmetry is centered between the second and third data segments of every quadruplet, e.g. between the 2.sup.nd and 3.sup.rd data segments, the 6.sup.th and 7.sup.th data segments, and so on, or mathematically as 2.5.sup.th, 6.5.sup.th, . . . , (2.5+4n).sup.th position. In mod-m mirroring, the m.sup.th data segment of input data packet 932 is swapped with the first, i.e. the 0.sup.th data segment; the 0.sup.th data segment is swapped with the m.sup.th element; and similarly the n.sup.th element is swapped with the (m?n).sup.th data segment to produce scrambled output data packet 938.

(384) Another scrambling method also shown in FIG. 51C is a frame-shift, where every data segment is shifted left or right by one, two, or more frames. For example, in a single frame phase shift, every data segment is shifted by one frame, where the first data segment is shifted to the second position; the second data segment is shifted to the third frame, and so on to produce scrambled output data packet 940. The last frame of input data packet 930, frame 1F in the example shown, is shifted to the first frame previously occupied by data segment 1A.

(385) In a 2-frame phase shift, the first data segment 1A of input data packet 930 is shifted by two frames into the position previously occupied by data segment 1C, the 4.sup.th frame 1D is shifted into the last position of scrambled output data packet 941, the next to the last data segment 1E is shifted into the first position and the last position 1F is shifted into the second position. Similarly, in a 4-frame phase shift, the data segments of input data packet 930 are shifted by four places with first frame 1A replacing the frame previously held by 1E, 1B replacing 1F, 1C replacing 1A, and so on, to produce scrambled output data packet 942. In the case of the maximum phase shift, the first frame replaces the last, the second frame originally held by 1 B becomes the first frame of output data packet 943, the second element is shifted into the first position, the third position into the second place, and so on. Phase-shifting one frame beyond the maximum phase shift results in output data unchanged from the input. The examples shown comprise phase-shifts where the data was shifted to the right. The algorithm also works for phase shiftsto the left but with different results.

(386) The aforementioned algorithms and similar methods as disclosed are referred herein to as static scrambling algorithms because the scrambling operation occurs at a single time, converting an input data set to a unique output. Moreover, the algorithms shown previously do not rely of the value of a data packet to determine how the scrambling shall occur. As illustrated in FIG. 51D, in accordance with the disclosed invention, parametric scrambling means the scrambling method is chosen from a table of possible scrambling algorithms, e.g. sort # A, sort # B, etc., based on a value derived from data contained within the data packet itself. For example, assume each data segment can be converted into a numerical value based on a calculation of the data contained within the data segment. One possible approach to determine the numerical value of a data segment is to employ the decimal or hexadecimal equivalent of the bit data in the data segment. If the data segment contains multiple terms, the numeric equivalent can be found by summing the numbers in the data segment. The data segment data is then combined into a single number or parameter and then used to select which scrambling method is employed.

(387) In the example shown, unscrambled data packet 930 is converted parametrically in step 950 into a data table 951, containing a numeric value for each data segment. As shown data segment 1A, the 0.sup.th frame, has a numeric value of 23, data segment 1B, the 1.sup.st frame, has a numeric value of 125, and so on. A single data packet value is then extracted in step 952 for the entire data packet 930. In the example shown, sum 953 represents the linear summation of all the data segment values from table 951, parametrically totaling 1002. In step 954 this parametric value, i.e. sum 953, is compared against a condition table, i.e. in software a set of predefined if-then-else statements, to compare sum 953 against a number of non-overlapping numerical ranges in table 955 to determine which sort routine should be employed. In this example, the parametric value of 1002 falls in the range of 1000 to 1499, meaning that sort # C should be employed. Once the sort routine is selected, the parametric value is then no longer required. The unscrambled data input 930 is then scrambled by the selected method in step 956 to produce the scramble data packet output 959. In the example shown, Sort # C, summarized in table 957, comprises a set of relative moves for each data segment. The first data segment of scrambled data packet 959, the 0.sup.th frame is determined by moving the 1D data segment to the left by three moves, i.e. a 3 shift. The 1.sup.st frame comprises data segment 1B, unchanged from its original position, i.e. a move of 0 places. The 2.sup.nd frame comprises 1E, a data segment shifted left by two moves from its original position. The same is true for the 3.sup.rd frame comprising data segment 1F shifted left by two moves from its original position. The 4.sup.th frame of scrambled data packet output 959 comprises data segment 1C shifted right, i.e. +2 moves, from its original position. The 5.sup.1h frame comprises data segment 1A, shifted five moves to the right, i.e. +5, from its original position.

(388) In this manner, summarized in table 957 for sort # C, every data segment is moved uniquely to a new position to create a parametrically determined scrambled data packet 959. To unscramble the scrambled data packet, the process is reversed, using the same sort method, sort # C. In order to insure that the same algorithm is selected to perform the unscrambling operation, the parametric value 953 of the data packet cannot be changed as a consequence of the scrambling operation. For example, using a linear summation of the parametric value of every data segment produces the same numerical value regardless of the order of the numbers.

(389) Dynamic scrambling utilizes a system state, e.g. time, to be able to identify the conditions when a data packet was scrambled, enabling the same method to be selected to perform the unscrambling operation. In the system shown in FIG. 51B, the state is used to generate a disguised numerical seed, which is transmitted to the sender or recipient of the package, which then uses the seed to select a scrambling algorithm from a table. Alternatively, the state itself may be transmitted to the sender or recipient, and the state may be used by a hidden number generator located in the sender or recipient to generate a hidden number that is used to select a scrambling/unscrambling algorithm. Such an arrangement is shown in FIG. 51E, where a state, e.g. time 920, is used to generate a hidden number 961, using hidden number generator 960, and to select a scrambling method from scrambling algorithm list 962. Using hidden number 961 to select an algorithm from scrambling algorithm table 962, scrambling operation 963 converts unscrambled data packet 930 into scrambled data packet 964. As shown in FIG. 51E, the state 920 may be passed directly to hidden number generator 960 or state 920 may be passed to hidden number generator via seed generator 921.

(390) The benefit of using a hidden number to select a scrambling algorithm instead of just a numeric seed, is it eliminates any possibility of a cybercriminal recreating the scrambling table by analyzing the data stream, i.e. statistically correlating repeated sets of scrambled data to corresponding numeric seeds. Although the seed may be visible in the data stream and therefore subject to spying, the hidden number generator and the hidden number HN it creates is based on a shared secret. The hidden number HN is therefore not present in the data stream or subject to spying or sniffing, meaning it is not transmitted across the network but generated locally from the numeric seed. This mathematical operation of a hidden number generator thereby confers an added layer of security in thwarting hackers because the purpose of the numeric seed is disguised.

(391) Once the algorithm is selected, the numeric seed may also be used as an input variable in the algorithm of scrambling process 963. Dual use of the numeric seed further confounds analysis because the seed does not directly choose the algorithm but works in conjunction with it to determine the final sequence of the scrambled data segments. In a similar manner, to unscramble a dynamically scrambled data packet, seed 929 (or alternatively the state or time 920) must be passed from the communication node, device or software initially performing the scrambling to any node or device wishing to unscramble it.

(392) In accordance with the disclosed invention, the algorithm of seed generation 921, hidden number generator 960, and the list of scrambling algorithms 962 represent shared secrets, information stored in a DMZ server (as described below) and not known to either the sender or the recipient of a data packet. The shared secret is established in advance and is unrelated to the communication data packets being sent, possibly during installation of the code where a variety of authentication procedures are employed to insure the secret does not leak. As described below, shared secrets may be limited to zones so that knowledge of one set of stolen secrets still does not enable a hacker to access the entire communication network or to intercept real-time communiqu?s.

(393) In addition to any shared secrets, in dynamic scrambling, where the scrambling algorithm varies during data packet transit, a seed based on a state is required to scramble or unscramble the data. This state on which the seed is based may comprise any physical parameter such as time, communication node number, network identity, or even GPS location, so long as there is no ambiguity as to the state used in generating the seed and so long as there is some means to inform the next node what state was used to last scramble the data packet. The algorithm used by the seed generator to produce a seed is part of the shared secrets, and hence knowledge of the seed does not allow one to determine the state on which the seed is based. The seed may be passed from one communication node to the next by embedding it within the data packet itself, by sending it through another channel or path, or some combination thereof. For example, the state used in generating a seed may comprise a counter initially comprising a random number subsequently incremented by a fixed number each time a data packet traverses a communication node, with each count representing a specific scrambling algorithm.

(394) In one embodiment of dynamic scrambling, during the first instance of scrambling a random number is generated to select the scrambling method used. This random number is embedded in the data packet in a header or portion of the data packet reserved for command and control and not subject to scrambling. When the data packet arrives at the next node, the embedded number is read by the communication node and used by the software to select the proper algorithm to unscramble the incoming data packet. The number, i.e. the count is next incremented by one count or some other predetermined integer, the packet is scrambled according to the algorithm associated with this new number, and the new count is stored in the data packet output overwriting the previous number. The next communication node repeats the process.

(395) In an alternative embodiment of the disclosed counter-based method for selecting a scrambling algorithm, a random number is generated to select the initial scrambling algorithm and this number is forwarded to every communication node used to transport the specific data packet as a shared secret. A count, e.g. starting with 0, is also embedded in the data packet in a header or portion of the data packet reserved for command and control and not subject to scrambling. The data packet is then forwarded to the next communication node. When the packet arrives at the next communication node, the server reads the value of the count, adds the count to the initial random number, identifies the scrambling algorithm used to last scramble the data packet and unscrambles the packet accordingly. The count is then incremented by one or any predetermined integer, and the count is again stored in the data packet's header or any portion of the data packet reserved for command and control and not subject to scrambling, overwriting the prior count. The random number serving as a shared secret is not communicated in the communication data packet. When the data packet arrives at the next communication node, the server then adds the random number shared secret added to the revised counter value extracted from the data packet. This new number uniquely identifies the scrambling algorithm employed by the last communication node to scramble the incoming packet. In this method, only a meaningless count number can be intercepted from the unscrambled portion of a data packet by a cyber-pirate has no idea what the data means.

(396) In another alternative method, a hidden number may be employed to communicate the state of the packet and what algorithm was employed to scramble it. A hidden number combines a time-varying state or a seed, with a shared secret generally comprising a numeric algorithm, together used to produce a confidential number, i.e. a hidden number that is never communicated between communication nodes and is therefore not sniffable or discoverable to any man-in-the middle attack or cyber-pirate. The hidden number is then used to select the scrambling algorithm employed. Since the state or seed is meaningless without knowing the algorithm used to calculate the hidden number and because the shared-secret algorithm can be stored behind a firewall inaccessible over the network or Internet, then no amount of monitoring of network traffic will reveal a pattern. To further complicate matters, the location of the seed can also represent a shared secret. In one embodiment, a number carried by an unscrambled portion of a data packet and observable to data sniffing, e.g. 27482567822552213, comprises a long number where only a portion of the number represents the seed. If for example, the third through eighth digits represent the seed, then the real seed is not the entire number but only the bolded numbers 27482567822552213, i.e. the seed is 48256. This seed is then combined with a shared secret algorithm to generate a hidden number, and the hidden number is used to select the scrambling algorithm, varying dynamically throughout a network.

(397) Also in accordance with the disclosed invention, yet another possible dynamic scrambling-algorithm is the process of dithering, intentionally introducing predictable noise into the data-stream in communication. One possible method of dithering involves the repeated transposition of two adjacent data segments occurring as a packet traverses the network. As illustrated in FIG. 51F, at time t.sub.0 corresponding to dynamic state 990, the unscrambled data packet 990 is scrambled by packet scrambling operation 926, resulting in scrambled data packet 1001 at time t.sub.1 corresponding to dynamic state 991. Data packet 1001 entering into communication node N.sub.1,1, hosted on server 971, comprises a series of data segments in the sequence 1D, 1B, 1E, 1F, 1C, 1A. Data packet 1001 is modified by communication node N.sub.1,1 at time t.sub.2 changing the data segment order by swapping data segments 1E and 1B. The resulting data packet 1002 comprising the data segment sequence 1D, 1E, 1B, 1F, 1C, 1A is then processed by communication node N.sub.1,2, hosted on server 972, at time t.sub.3 returning the sequence back to 1D, 1B, 1E, 1F, 1C, 1A. With each successive node, the relative positions of data segments 1B and 1E are swapped, or dithered, making no two successive packets the same. As such, the original scramble sequence comprises data packets 1001, 1003, 1005 and 1007 at corresponding times t.sub.1, t.sub.3, t.sub.5 and t.sub.7 with altered data packets 1002, 1004, and 1006 at corresponding times t.sub.2, t.sub.4 and t.sub.6. Data packet 1007 output from communication node N.sub.1,6, hosted on server 972, is then unscrambled by packet unscrambling operation 928 to recover the original data sequence 930 at time t.sub.f.

(398) One example of static scrambling in accordance with the disclosed secure dynamic network and protocol and applied to a data packet 930 traversing a string of communication servers 1010 to 1015 is illustrated in FIG. 52, where communication node N.sub.0,0, hosted on server 1010, includes packet-scrambling operation 926, resulting in scrambled data packet 1008. Scrambled packet 1008 then traverses a packet-switched communication network without any further changes to the data segment sequence where communication node N.sub.0,f, hosted on server 1015, finally performs packet-unscrambling operation 928 returning the data packet to its original sequence. This form of data transport represents static scrambling because the data packet, once initially scrambled, does not change traversing the network until it reaches the last server.

(399) The data shown traversing the network, albeit scrambled, can be referred to as plaintext because the actual data is present in the data packets, i.e. the packets have not been encrypted into ciphertext. By contrast, in ciphertext the character string comprising the original data, whether scrambled or not, is translated into a meaningless series of nonsense characters using an encryption key, and cannot be restored to its original plaintext form without a decryption key. The role of encryption in the disclosed SDNP based communication is discussed further in the following section on Encryption.

(400) In order to change the sequence of data packets during transport through the network, packet re-scrambling is required, as shown in FIG. 53. The process of packet re-scrambling returns a scrambled data packet to its unscrambled state before scrambling it again with a new scrambling algorithm. Thus, the term re-scrambling as used herein, means unscrambling a data packet and then scrambling it again, typically with a different scrambling algorithm or method. This approach avoids the risk of data corruption that could occur by scrambling a previously scrambled package and losing track of the sequence needed to restore the original data. As shown, once initially scrambled by packet scrambling operation 926, scrambled data packet 1008 is re-scrambled, first by unscrambling it with unscrambling operation 928, using the inverse operation of the scrambling algorithm used to scramble the data, and then by scrambling the data packet anew with scrambling operation 926, using a different scrambling algorithm than used in the prior scrambling operation 926. The resulting re-scrambled data packet 1009 differs from the prior scrambled data packet 1008. Re-scrambling operation 1017 comprises the successive application of unscrambling followed by scrambling, referred to herein as US re-scrambling, where US is an acronym for unscrambling-scrambling. To recover the original data packet 930, the final packet unscrambling operation 928 requires using the inverse function of the same algorithm used to last re-scramble the data packet.

(401) The application of US re-scrambling in a SDNP-based packet-switched communication network in accordance with the invention is illustrated in FIG. 54, where data packet 930 first scrambled by scrambling operation 926 in server 1011, is successively modified by US re-scrambling operation 1017 as the data packet traverses network of packet switch communication servers 1012 through 1015. The final unscrambling operation 928 occurs in server 1016, restoring data packet 930 to its original sequence. Since the re-scrambling occurs repeatedly and at different times from time t.sub.0 to t.sub.f; the resulting network represents a dynamically scrambled communication network. In operation, unscrambled data packet 930 is scrambled using scrambling operation 926 implemented within communication node N.sub.0,0 hosted on server 1011. Using US re-scrambling operation 1017 implemented within communication node N.sub.0,1, hosted on server 1012, the packet is modified into scrambled data packet 1008 at time t.sub.2. The same process repeats again each time the data packet transits through the remaining communication nodes. For example, within communication node N.sub.0,2, hosted on server 1013, US re-scrambling operation 1017 converts re-scrambled data packet 1008 into a new re-scrambled data packet 1009.

(402) Each re-scrambling operation 1017 first undoes the prior scrambling by relying on the prior state of the packet entering the communication node, e.g. where data packet 1008 was scrambled with a state corresponding to time t.sub.2, and then scrambles the packet anew with a new state corresponding to time t.sub.3 to create re-scrambled data packet 1009. As described previously, the state used in determining the scrambling performed may involve a seed, a time, or a number based on any physical parameter such as time, communication node number, network identity, or even GPS location, so long that there is no ambiguity as to how the scrambling was last performed. Accordingly, unscrambling the input data packet to communication node N.sub.0,1, hosted on server 1012, relies on the state of the prior server used to scramble the data packet, i.e. the state of communication node N.sub.0,0, hosted on server 1011; unscrambling the data packet entering communication node N.sub.0,2, hosted on server 1013, relies on the state of communication node N.sub.0,1, hosted on server 1012, at the time of scrambling, unscrambling the data packet entering communication node N.sub.0,3, hosted on server 1014, relies on the state of communication node N.sub.0,2, hosted on server 1013, at the time of scrambling, and so on. The last communication node in the communication network, in this case communication node N.sub.0,f; hosted on server 1016, does not perform US re-scrambling but instead only performs unscrambling operation 928 to restore data packet 93090 to its original unscrambled sequence.

(403) In accordance with the disclosed invention, the static and dynamic scrambling of data renders interpretation of the unscrambled data meaningless, reordering sound into unrecognizable noise, reordering text into gibberish, reordering video into video snow, and scrambling code beyond repair. By itself, scrambling provides a great degree of security. In the SDNP method disclosed herein, however, scrambling is only one element utilized to provide and insure secure communication free from hacking, cyber-assaults, cyber-piracy, and man-in-the-middle attacks.

(404) Packet Encryption

(405) In accordance with the disclosed invention, secure communication over a packet-switched network relies on several elements to prevent hacking and ensure security, one of which involves SDNP encryption. As described previously, encryption from the Greek meaning to hide, to conceal, to obscure represents a means to convert normal information or data, commonly called plaintext, into ciphertext comprising an incomprehensible format rendering the data unreadable without secret knowledge. In modern communication, this secret knowledge generally involves sharing one or more keys used for encrypting and decrypting the data. The keys generally comprise pseudo-random numbers generated algorithmically. Numerous articles and texts are available today discussing the merits and weaknesses of various encryption techniques such as Cryptonomicon by Neal Stephenson? 1999, The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography by Simon Singh? 1999, Practical Cryptography by Niels Ferguson? 2013, and Cryptanalysis: A Study of Ciphers and Their Solution first published in 1939.

(406) While the concept of encryption or ciphers is ancient and well known to those skilled in the art, the application of cryptography in the disclosed secure dynamic network and protocol is unique, facilitating both end-to-end encryption and single-hop node-to-node dynamic encryption to the network architecture itself, independent of any client's own encryption. SDNP communication is architected with the basic precept that given sufficient time, any static encrypted file or message can eventually be broken and its information stolen, no matter how sophisticated the cipher. While this supposition may in fact be incorrect, there is no need to prove or disprove the proposition because the converse, i.e. waiting till a specific encryption method fails, may result in unacceptable and irreversible consequential damage.

(407) Instead, SDNP communication is based on the premise that all encrypted files have a limited shelf life, metaphorically meaning that encrypted data is good (secure) for only a finite period of time and that the confidential data must be re-encrypted dynamically at regular intervals, ideally far more frequently than the best estimates of the time required to crack its encryption with state-of-the-art computers. For example, if it is estimated by cryptologists that a large server farm of crypto-engines can break a given cipher in one year, then in SDNP communication a data packet will be re-encrypted every second or even every 100 ms, intervals many orders of magnitude shorter than the best technology's capability to crack it. As such, SDNP encryption is necessarily dynamic, i.e. time variant, and may also be spatially variant, i.e. depending on a communication node's location in a packet-switched network or geography. Thus, as used herein, the terms re-encrypting or re-encryption refer to decrypting a data packet and then encrypting it again, typically with a different encryption algorithm or method.

(408) SDNP encryption therefore involves converting data from unencrypted plaintext into ciphertext repeatedly and frequently, rendering the information incomprehensible and useless. Even if a given packet's data encryption is miraculously broken, by employing SDNP's dynamic encryption methods, the next data packet utilizes a completely different encryption key or cipher and requires a completely new effort to crack its encryption. By limiting the total content of each uniquely encrypted data packet, the potential damage of unauthorized access is mitigated because an exposed data packet contains, by itself, a data file too small to be meaningful or useful by a cyber-pirate. Moreover, by combining dynamic encryption with the aforementioned SDNP scrambling methods, communication security is enhanced tremendously. Even in its unencrypted form, the intercepted data file contains only a small snippet of data, voice, or video scrambled into a meaningless and incomprehensible sequence of data segments.

(409) In accordance with this invention, SDNP encryption is dynamic and state-dependent. As shown in FIG. 55A, an unencrypted data packet comprising plaintext 930, processed through encryption operation 1020, results in an encrypted data packet comprising ciphertext 1024 or 1025. In the case of ciphertext 1024, the entire data packet of plaintext 930 is encrypted in toto, treating data segments 1A through 1F as a single data file. In the case of ciphertext 1025, each data segment 1A through 1F of plaintext 930 is encrypted separately and distinctly, and is not merged with other data segments. First data segment 1A is encrypted into a corresponding first ciphertext data segment shown for illustration purposes by a string of characters starting with 75 and comprising a long string of characters or digits not shown. Similarly, second plaintext data segment 1B is encrypted into second ciphertext data segment comprising a long string of characters shown for illustrative purposes starting with *^. The characters 7$ and *^ are meant to illustrate the beginning of meaningless strings of symbols, digits, and alphanumeric characters and not to limit or imply anything about the specific data in the plaintext source or the length of the character strings being encrypted.

(410) Encryption operation 1020 can use any algorithm, cryptographic, or cipher method available. While the algorithm may represent a static equation, in a one embodiment the encryption operation uses dynamic variables or states such as time 920 when encryption occurs, and an encryption generator 1021 to produce E-key 1022, which also may be dependent on a state such as time 920 at which the encryption was performed. For example, the date and time of encryption may be used as a numeric seed for generating an encryption key that cannot be recreated even if the encryption algorithm were discovered. Time 920 or other states may also be used to select a specific algorithm from an encryption algorithms list 1023, which is a list of available encryption algorithms. In data flow diagrams, it is convenient to illustrate this packet encryption operation and sequence using a schematic or symbolic representation, as depicted herein by the symbol shown for encryption operation 1026. Throughout this invention disclosure, a padlock may also symbolically represent secure and encrypted data. Padlocks with a clock face located atop the padlock specifically indicate a secure delivery mechanism, e.g., encrypted files that, if not received within a specific interval or by a specific time, self-destruct and are lost forever.

(411) The decryption operation shown in FIG. 55B illustrates the inverse function of encryption operation 1020, specifically decryption operation 1031, where the state or time 920 and other states used to create ciphertext 1024, along with a decryption key or D-key 1030 generated by D-key generator 1029 are re-used for undoing the encryption, i.e. decrypting the file, to produce unencrypted data comprising original plaintext data packet 990. Using the same state or time 920 employed when the packet encryption first occurred, the same encryption operation that was selected from encryption algorithm list 1023 may be used again in the decryption operation 1031. Although encryption algorithm list 1023 references the term encryption, the same algorithm table is used to identify and select the inverse function needed for performing decryption, i.e. encryption algorithm list 1023 contains the information needed both for encrypting and decrypting data packets. Because the two functions involve the same steps performed in reverse order, table 1023 could also be renamed as encryption/decryption algorithms table 1023. For clarity's sake however, the table is labeled only by the function and not by its anti-function.

(412) Should the encryption algorithm selected for implementing decryption operation 1031 not match the inverse of the original algorithm employed in packet encryption operation 1020, should state or time 920 not match the time encryption occurred, or should D-key 1030 not have a predefined numeric relationship to E-key 1022 used during encryption, then the decryption operation 1031 will fail to recover the original unencrypted data 990 and the packet data will be lost. In data flow diagrams, it is convenient to illustrate this packet decryption operation and sequence using a schematic or symbolic representation, as depicted herein by the symbol shown for decryption operation 1032.

(413) As described previously in this disclosure, knowledge regarding the use of encryption and decryption keys in cryptography and of common encryption algorithms, such as symmetric public key encryption, RSA encryption, and AES256 encryption among others, are commonplace and well known to those skilled in the art. The application of such well known cryptographic methods in the disclosed SDNP communication system is, however, not readily susceptible to hacking or decryption because of hidden information, shared secrets, and time-dependent dynamic variables and states unique to the disclosed SDNP communication.

(414) So even in the unlikely case where a cyber-pirate has sufficient computer power to eventually crack a robust encryption method, they lack certain information embedded into the SDNP network as non-public or shared secrets required to perform the decryption operation, and must also crack the encryption in a fraction of a second before the encryption changes. Moreover every data packet traversing the disclosed SDNP network utilizes a different encryption method with unique keys and dynamic states. The combination of missing information, dynamic states, and limited informational content contained within any given packet, renders obtaining meaningful data theft from any given data packet both challenging and unrewarding to a cyber-pirate.

(415) In order to intercept an entire document, video stream, or voice conversation to reconstruct a coherent data sequence, a cyber-assault must successively crack and decrypt not one but thousands of successive SDNP packets. The daunting challenge of continuously hacking a succession of SDNP packets is further exacerbated by combining dynamic encryption with the previously described methods regarding data packet scrambling. As illustrated in FIG. 56, the creation of an encrypted, scrambled data packet 1024 involves the successive combination of scrambling operation 926 and encryption operation 1026 to convert un-scrambled plaintext data packet 990 first into scrambled plaintext data packet 1008 and then into ciphertext 1024 of the scrambled data packet. To undo the encrypted scrambled package, the inverse functions must be applied in reverse sequence first by decryption operation 1032 to recover scrambled plaintext data packet 1035, then by unscrambling operation 928 to recover unscrambled plaintext data packet 990.

(416) As shown, scrambling and encryption represent complementary techniques in achieving secure communication. Unencrypted scrambled data traversing the network, is referred to as plaintext because the actual data is present in the data packets, i.e. the packets have not been encrypted into ciphertext. Encrypted data packets, or ciphertext, comprise scrambled or unscrambled character strings translated into a meaningless series of nonsense characters using an encryption key, and cannot be restored to its original plaintext form without a corresponding decryption key. Depending on the algorithm employed, the encryption and decryption keys may comprise the same key or distinct keys mathematically related by a predefined mathematical relationship. As such, scrambling and encryption represent complementary techniques in achieving secure communication in accordance with the disclosed invention for SDNP communication.

(417) The two methods, scrambling and encryption, can be considered independently even when used in combination, except that the sequence used to restore the original data packet from an encrypted scrambled data packet must occur in the inverse sequence to that used to create it. For example, if the data packet 990 was first scrambled using scrambling operation 926 and then encrypted using encryption operation 1026, then to restore the original data packet, the encrypted scrambled data packet 1024 must first be decrypted using decryption operation 1032 and then unscrambled using unscrambling operation 928. Mathematically, if a scrambling operation F scrambles a string of bits or characters into an equivalent scrambled version and an unscrambling operation F.sup.?1 undoes the scrambling, whereby
F.sup.?1[F(A)]=A
and similarly if an encryption operation G encrypts a string of plaintext into equivalent ciphertext and a decryption operation G.sup.?1 undoes the encryption whereby
G.sup.?1[G(A)]=A
then in combination, the successive operation of scrambling and then encrypting followed by decrypting and then unscrambling returns the original argument A, the unscrambled plaintext data packet. Accordingly,
F.sup.?1{G.sup.?1[G(F(A))]}=A
because the sequence occurs in inverse order, specifically decrypting [G.sup.?1] encrypted scrambled packet [G(F(A))] restores scrambled plaintext data packet F(A). Subsequent unscrambling operation F.sup.?1 of scrambled plaintext packet F(A) restore the original data packet A.

(418) Provided linear methods are employed, the sequence is reversible. For example, if the data packet is first encrypted and then scrambled, then to restore the original data packet the scrambled ciphertext must first be unscrambled and then decrypted. Accordingly,
G.sup.?1{F.sup.?1[F(G(A))]}=A
Changing the sequence does not work. Decrypting a data packet that was previously encrypted and then scrambled without first unscrambling it will not recover the original data packet, i.e.
F.sup.?1{G.sup.?1[F(G(A))]})?A
Similarly unscrambling a packet that was scrambled and then encrypted will also fail to restore the original data packet, because
G.sup.?1{F.sup.?1[G(F(A))]}?A

(419) To summarize, if the plaintext packet is scrambled before it is encrypted, it must be decrypted before it is unscrambled; if the plaintext packet is encrypted before it is scrambled, it must be unscrambled before it is decrypted.

(420) While it is understood that scrambling and encrypting may be performed in either sequence, in one embodiment of the SDNP methods in accordance with this invention, encryption and decryption occur more frequently during network transport than scrambling and therefore encryption should occur after scrambling and decryption should occur before unscrambling, as illustrated in FIG. 56, rather than the converse. For convenience, we define the combination of packet scrambling operation 926 followed by encryption operation 1026 as encrypting scrambled packet operation 1041, and its converse, the combination of decryption operation 1032 followed by packet unscrambling operation 928 as unscrambling decrypted packet operation 1042. These hybridized operations may be employed in static and dynamic SDNP communication in accordance with this invention.

(421) In FIG. 57, representing SDNP communication, plaintext packet 990 traverses a series of communication nodes 1011 to 1016 of a packet-switched communication network in a statically encrypted and scrambled form, represented by ciphertext data packet 1040, which does not change from node-to-node or with time. As shown in the first server, N.sub.0,0 communication node 1101, the scrambling encryption operation 1041 is employed to convert the original plaintext data packet 990 into ciphertext data packet of encrypted, scrambled data. Once converted at time t.sub.1 and corresponding state 991, the encrypted scrambled data packet remains static and unchanged as the data packet traverses the network until finally reaching N.sub.0,f communication node 1016, where the data packet is returned to its original form of plaintext data packet 990 by decryption unscrambling operation 1042 at time t.sub.f. While the combination of scrambling and encryption greatly enhances security, it does not represent dynamic security because the data packets remain unchanged over time and during transit.

(422) One means to enhance to enhance security in any implementation using static scrambling encryption is to insure that each data packet sent is subjected to different scrambling and/or encryption methods, including changes in state, seeds, and/or keys at time t.sub.1 when each data packet enters the communication network.

(423) However, a more robust alternative involves dynamically changing a data packet's encryption or scrambling, or both, as the packet traverses the network in time. In order to facilitate the required data processing to realize a fully dynamic version of SDNP communication, it is necessary to combine the previously defined processes in order to re-scramble (i.e., unscramble and then scramble) and re-encrypt (i.e., unencrypt and then encrypt) each packet as it passes through each communication node in a packet-switched communication network. As used herein the term re-packet or re-packeting will sometimes be used to refer to the combination of re-scrambling and re-encryption, whether the packet is initially decrypted before it is unscrambled or unscrambled before it is decrypted. In either case, the unscrambling and decryption operations at a given node should be performed in an order that is the reverse of the scrambling and encryption operations as the packet left the prior node, i.e., if the packet was scrambled and then encrypted at the prior node, it should first be decrypted and then unscrambled at the current node. Typically, the packet will then be scrambled and then encrypted as it leaves the current node.

(424) The re-packet operation at a communication node is illustrated in FIG. 58, where an incoming ciphertext data packet 1040 is first decrypted by decryption operation 1032, then unscrambled by unscrambling operation 928 to recover the unscrambled plaintext data packet 990 containing the content of the original packet. If any information within the packet must be inspected, parsed, split, or redirected, the unscrambled plaintext file is the best format in which to perform such operations. The plaintext data packet 990 is then again scrambled using scrambling operation 926 followed by a new encryption performed by encryption operation 1026 to produce a new scrambled ciphertext data packet 1043. Since the re-packet operation of incoming scrambled ciphertext data packet 1040 occurs successively by decryption, unscrambling, scrambling and encryption, the acronym DUSE re-packet operation 1045 is used herein to denote the disclosed technique in accordance with this invention. In a dynamic secure network, the state or time, the decryption key, and any seeds used for performing decryption operation 1032 and unscrambling operation 928 are preferably different than the state or time, seeds or encryption keys used for executing scrambling operation 926 and encryption operation 1026.

(425) The DUSE re-packet operation 1045 as described can be implemented as software, firmware or as hardware within any communication node. In general, it is preferred to utilize software to implement such operations, since the software code can be updated or improved over time. The application of DUSE re-packet operation 1045 in a dynamic network is illustrated in FIG. 59, where communication node N.sub.0,0, hosted on server 1011, performs encrypting scrambled packet operation 1041, communication node N.sub.0,f, hosted on server 1016, performs decryption unscrambling operation 1042, while the intermediate communication nodes N.sub.0,1 through N.sub.0,4, hosted on servers 1012 through 1015, respectively, perform DUSE re-packeting operations 1045. In operation, plaintext data packet 990 is first processed by scrambling encryption operation 1041 in communication node N.sub.0,0, then processed by DUSE re-packeting operation 1045 in communication node N.sub.0,1 producing re-packeted scrambled plaintext 1008 representing the packet after decryption, packet unscrambling, and packet scrambling yet prior to encryption. Scrambled plaintext 1008 is then subsequently encrypted to form ciphertext 1040 at time t.sub.2 and corresponding state 992. The process repeats again in communication node N.sub.0,2 and again in communication node N.sub.0,3, producing re-packeted scrambled plaintext 1009 subsequently encrypted to form ciphertext 1048 at time t.sub.4 and corresponding state 994. Finally, communication node N.sub.0,f performs unscrambling decrypting operation 1042 to restore unscrambled plain text 990 at time t.sub.f.

(426) Packet Mixing and Splitting

(427) Another key element of the secure dynamic network and protocol disclosed herein is its ability to split data packets into sub-packets, to direct those sub-packets into multiple routes, and to mix and recombine the sub-packets to reconstruct a complete data packet. The process of packet splitting is illustrated in FIG. 60A, where data packet 1054 is split, using splitting operation 1051 combined with algorithmic parse operation 1052 and with junk operation 1053, which has the ability to insert or remove non-data junk data segments. Analogous to junk DNA present in the human genome, junk data segments are inserted by junk operation 1053, to extend or control the length of a data packet, or as needed to remove them. Junk operation 1053 is especially important when there is an inadequate amount of data to fill a packet. The presence of junk data segments inserted into a data packet also makes it difficult for cyber-pirates to distinguish real data from noise. As used herein, a junk packet or data segment is a packet or data segment that consists entirely of meaningless data (bits). These junk bits can be introduced into a stream of data packets obfuscating real data in a sea of meaningless bits.

(428) The purpose of parse operation 1052 is to break data packet 1054 into smaller data packets, e.g. data sub-packets 1055 and 1056, for processing of each of the constituent components. Breaking data packet 1054 into smaller pieces offers unique advantages such as supporting multipath transport, i.e. transmitting the data packets over multiple and different paths, and facilitating unique encryption of constituent sub-packets using different encryption methods.

(429) The splitting operation can use any algorithm, numerical method, or parsing method. The algorithm may represent a static equation or include dynamic variables or numerical seeds or states such as time 920 when the incoming data packet 1054 was first formed by a number of sub-packets, and a numerical seed 929 generated by seed generator 921, which also may be dependent on a state such as time 920 at the time of the data packet's creation. For example, if each date is converted into a unique number ascending monotonically, then every seed 929 is unique. Time 920 and seed 929 may be used to identify a specific algorithm chosen from a list of available methods, i.e. from algorithm 1050. Packet splitting, or un-mixing, comprises the inverse procedure of mixing, using the same algorithm executed in the precise reverse sequence used previously to create the specific packet. Ultimately everything that is done is undone but not necessarily all in one step. For example, a scrambled encrypted data packet might be decrypted but remain scrambled. Processed by splitting operation 1051, un-split incoming data packet 1054 is converted into multiple data packets, e.g. split fixed-length packets 1055 and 1056 using parse operation 1052 to algorithmically perform the operation. In data flow diagrams, it is convenient to illustrate this packet splitting operation 1051 including parsing 1052 and junk operation 1053 using a schematic or symbolic representation, as depicted herein by the symbol shown for splitting operation 1057.

(430) Thus, as used herein, the term splitting may include parsing, which refers to the separation of a packet into two or more packets or sub-packets, and it may also include the insertion of junk packets or sub-packets into the resulting parsed packets or sub-packets or the deletion of junk packets or sub-packets from the resulting parsed packets or sub-packets.

(431) The inverse function, packet-mixing operation 1060 shown in FIG. 60B, combines multiple packets 1055 and 1056 together to form mixed packet 1054. Like packet splitting, the packet mixing operation can use any algorithm, numerical method, or mixing method. The algorithm may represent a static equation or include dynamic variables or numerical seeds or states such as time 920 used to specify the conditions when incoming data packets 1055 and 1056 are mixed. The mixing operation used to create the data packet may utilize numerical seed 929 generated by seed generator 921, which also may be dependent on a state such as time 920. Time 920 and seed 929 may be used to identify a specific mixing algorithm chosen from a list of available mixing methods, i.e. from mixing algorithms 1050. In data flow diagrams, it is convenient to illustrate this packet mixing operation using a schematic or symbolic representation, as depicted herein by the symbol shown for mixing operation 1061.

(432) In accordance with this invention, packet mixing and splitting may utilize any of a large number of possible algorithms. FIG. 61A illustrates three of many possible mixing techniques comprising concatenation, interleaving, or algorithmic methods. In concatenation, the data segment sequence of data packet 1056 is appended onto the end of data packet 1055 to create mixed packet 1054. In interleaving, the data segments of data packets 1055 and 1056 are intermixed in alternating fashion, i.e. as 1A, 2A, 1B, 2B, etc. to form mixed data packet 1065. Other methods used for packet mixing involve an algorithm. In the example shown, an algorithm comprising interleaved reflective symmetry alternates the data segments in the order of 1A, 2A, 1B, 2B, 1C, 2C in the first half of the mixed packet 1066, and in the opposite order for the second half, i.e. 2D, 1D, 2E, 1E, 2F, 1F.

(433) An example of the application of packet mixing using concatenation in accordance with this invention is illustrated in FIG. 61B. As shown, at time t.sub.0 unmixed data packets 1055 and 1056 are mixed in communication node N.sub.0,0, hosted on server 1011, using mixing operation 1061. The resulting merged data packet 1066 comprising the sequence 1A through 1F followed by 2A through 2F is then transported through a network of servers 1011 to 1016 comprising unchanged plaintext, static in its composition over all times 998, until in communication node N.sub.0,f, hosted on server 1016, the packet splitting operation 1057 separates the components of mixed data packet 1066 into the original data packets 1055 and 1056

(434) Similarly, an example of the application of interleaved mixing in accordance with this invention is illustrated in FIG. 61C. Identical in sequence to the previous example, the resulting mixed packet 1066 has a sequence 1A, 1B, 2A, 2B, 3A, 3B . . . . Although the mixed packet is different that the concatenated example, packet data splitting operation 1057 is able to restore the original unmixed data packets 1055 and 1056 because the knowledge of the mixing algorithm and the time, state, or seeds used in the mixing operation is passed to communication node N.sub.0,f, hosted on server 1016, either as part of data packet 1066 or prior to packet communication at time t.sub.0.

(435) Scrambled Mixing

(436) The disclosed methods of packet communication using the splitting and mixing of data packets into various combinations of data segments can in accordance with the disclosed invention be combined with packet scrambling in numerous ways. In FIG. 62A unscrambled plaintext data-packets 1055 and 1056 are mixed using mixing operation 1061 resulting in mixed data packet 1067, in the example shown formed using interleaved plaintext. After mixing, data packet 1067 is scrambled by scrambling operation 926 to produce scrambled plaintext data packet 1068. The combined sequence of packet mixing operation 1061 and packet scrambling 926 together comprises mixing and scrambling operation 1070, comprising mixing followed by scrambling.

(437) In an alternative implementation in accordance with this invention, individual data packets are first scrambled then mixed as shown in FIG. 62B. In this implementation, unscrambled plaintext data packets 1055 and 1056 are first scrambled by separate and independent scrambling operations 926, thereby resulting in corresponding scrambled plaintext data packets 1008 and 1009. These scrambled packets are then mixed together by mixing operation 1061 resulting in mixed scrambled data packet 1069.

(438) The combined use of mixing and scrambling as disclosed may be integrated into either static or dynamic SDNP communication networks. In FIG. 63, plaintext data packets 1055 and 1056 are input into communication node N.sub.0,0, hosted on server 1011, which performs mixing and scrambling operation 1070, comprising mixing operation 1061 followed by scrambling operation 926, to form mixed scrambled packet 1068. The packet content remains constant at all times to as the mixed scrambled packet 1068 traverses servers 1011 to 1016. Final communication node N.sub.0,f; hosted on server 1016, then performs unscrambling operation 928 followed by splitting operation 1057, represented as unscrambling and splitting operation 1044.

(439) FIG. 64 illustrates an example of dynamic scrambled mixing in a SDNP communication network. As in the prior static SDNP example, plaintext data packets 1055 and 1056 are input into communication node N.sub.0,0, hosted on server 1011, which performs mixing and scrambling operation 1070, comprising mixing followed by scrambling. The mixed scrambled packet is the subjected to a US re-scrambling operation 1010 in server 1012 to form a mixed scrambled packet 1072 at time t.sub.2 corresponding to state 992. Servers 1013 and 1014 then perform US re-scrambling operation 1017 to repeatedly unscramble and then re-scramble the data packet. The US re-scrambling operation is repeated in communication node N.sub.0,4, hosted on server 1015, resulting in newly re-scrambled data packet 1073 at time t.sub.5 corresponding to state 995. Final communication node N.sub.0,f, hosted on server 1016, then performs unscrambling splitting operation 1044 to recover packets 1055 and 1056. In the dynamic network implementation shown, the unscrambling operation used in each US re-scrambling operation 1017 utilizes the time or state of the data packet created in the prior server then re-scrambles the data packet at the current time. For example, data packet 1072, created at time t.sub.2 in server 1012 is re-scrambled in server 1013, i.e., unscrambled, using the state associated with time t.sub.2, and then scrambled again using the state associated with the current time (not shown). As such, FIG. 64 illustrates by example that mixing and splitting operations can nest repeated and successive operations of scrambling and unscrambling.

(440) Encrypted Scrambled Mixing

(441) The disclosed methods of packet communication using the splitting and mixing of data packets into various combinations of sub-packets combined with packet scrambling can, in accordance with the disclosed invention be combined with encryption. FIG. 65 illustrates several examples of functions combining mixing, scrambling and encryption and their corresponding inverse functions. One example is mixing scrambling encryption or MSE operation 1075, comprising a sequence of mixing operation 1061, followed by scrambling operation 926, and lastly encryption operation 1026. The inverse function, decryption unscrambling splitting, or DUS operation 1076, comprises the inverse sequence of operations, namely decryption operation 1032, unscrambling operation 928, and splitting operation 1057. The output of MSE operation 1075 and the input of operation DUS 1076 involve ciphertext. To communicate and recover the original content, albeit in pieces, the same shared secrets, numeric seeds, and encryption/decryption keys used to create a ciphertext packet must be used to undo it.

(442) Intermediate nodes may involve only re-encryption operation 1077, comprising the combination of decryption operation 1032 and encryption operation 1026, or may involve DUSE operation 1045 sequentially comprising the functions of decryption operation 1032, unscrambling operation 928, Scrambling operation 926, and encryption operation 1026. In re-encryption operation 1077 and DUSE operation 1045 the functions of decryption operation 1032 and unscrambling operation 928 may require the seeds or key of the communication node sending the packet to them at a prior time or state. The functions of encryption operation 1026 and re-scrambling operation 926 may both employ information, seeds, and keys generated at the present time or state, i.e. at the time a communication node refreshes a data packet. Data packet refreshing makes it more difficult for cyber-assaults to access information in a data packet because the packet data in newly obfuscated and the time available to break the code is shortened.

(443) One example of the use of dynamic combinational mixing, scrambling, and encryption and their inverse functions is illustrated in FIG. 66A where two data packets 1055 and 1056 enter communication node N.sub.0,0, hosted on server 1011, at time t.sub.0. The two packets may represent the same kind of data types, e.g. two voice packets, two text message files, two documents, two pieces of software, etc. or may represent two dissimilar types of information, e.g. one voice packet and one text file, one text packet, and one video or photo image, etc. Then, at time t.sub.1 using state 991 information for generating keys, numeric seeds, or other secrets, communication node N.sub.0,0, hosted on server 1011, performs mixing scrambling encryption (MSE) operation 1075. The result is a scrambled data packet in ciphertext format, illegible and interpretable to any observer not in possession of the state information used to create it. Also at time 11, a numerical seed representing the time or state when packet mixing occurred is generated and passed to final node N.sub.0,f; either by sending this information ahead of the mixed data packet, or alternatively embedding this seed into the data packet itself in a packet header (described later in this disclosure).

(444) The data is next passed to communication node N.sub.0,1, hosted on server 1012, which performs DUSE operation 1045, decrypting and unscrambling the incoming data based on state 991 information corresponding to time t.sub.1 then refreshing the security by scrambling and encrypting the data again based on state 992 information, corresponding to time t.sub.2. If state information 991 is being passed to final node N.sub.0,f by embedding it in the data packet or its header, then two copies of the state information are requiredone to be used by final node N.sub.0,f, comprising state 991 when mixing occurred, and a second state used by the DUSE operation changing each time the data packet hops from one node to the next, i.e. from state 991 to 992, 993, etc. Using the state of the last operation performed on an incoming data packet, DUSE operation 1045 performs re-scrambling on unencrypted data by decrypting it first, performing the re-scrambling, then encrypting the data again, i.e. the re-scrambling operation is nested within a re-encryption operation. The resulting outgoing data packet comprises ciphertext 1080B with underlying unencrypted content represented by plaintext 1080A. DUSE operation 1045 is repeated successively in servers 1013, 1014, and 1015, resulting in ciphertext 1081B with underlying unencrypted content represented by plaintext 1081A at time t.sub.5. Communication is completed by communication node N.sub.0,f, hosted on server 1016, which performs decryption unscrambling splitting (DUS) operation 1076, decrypting, unscrambling the incoming data packet based on state 995 information corresponding to time t.sub.5 used to last refresh it, then splitting the packet in accordance with state 991 when mixing first occurred. Since the intermediate nodes are unaware of the mixing condition, even a network operator with access to the intermediate nodes is unaware of the conditions used at mixing. The resulting plaintext outputs 1055 and 1056 at time t.sub.f recover the data sent across the network starting at time t.sub.0. Since the packet's content was re-scrambled and re-encrypted as the packet passes through each node N.sub.0,x where x=0, 1, 2, . . . f, the opportunity for intercepting and interpreting the data packets being communicated is extremely complex and provides little time for hacking.

(445) A simpler method for establishing secure communication involves mixing and scrambling of the packet at the beginning of the communication but utilizes repeated steps of re-encryption. Unlike the fully dynamic encrypted scrambling and mixing example of the prior illustration, FIG. 66B combines static mixing and scrambling in server 1011 with dynamic encryption in servers 1011-1015, meaning only the encryption changes with time. The communication commences at time t.sub.0, starting with data packets 1055 and 1056 delivered to communication node N.sub.0,0, hosted on server 1011. As in the prior example the two packets may represent any mix of data types including voice packets, text messages, documents, software, video or photo images, etc.

(446) Then at time t.sub.1, using state 991 information for generating keys, numeric seeds, or other secrets, communication node N.sub.0,0 performs mixing scrambling encryption (MSE) operation 1075. The resulting ciphertext 1082B is a scrambled data packet in ciphertext format, illegible and interpretable to any observer not in possession of the state information used to create it. The underlying data packet comprising plaintext 1082A is scrambled and even without encryption is also incomprehensible to cyber-pirates attempting to recover the source data, text, picture, or sound without the state information, keys, seeds, and secrets.

(447) The data is next passed to communication node N.sub.0,1, hosted on server 1012, which, rather than performing the DUSE operation as in the previous example, only re-encrypts the incoming data, i.e. decrypts the data based on state 991 information corresponding to time t.sub.1 then encrypts it again based on state 992 information corresponding to the current time t.sub.2. The process, shown as re-encryption operation 1077, results in outgoing data packet comprising ciphertext 1083B with underlying scrambled plaintext 1083A identical to previous plaintext 1082A. A re-encryption operation 1077 is repeated successively in servers 1013, 1014, and 1015 resulting in new ciphertext. For example ciphertext 1084B and underlying unchanged plaintext 1084A represent the data traveling between servers 1013 and 1014. The underlying plaintext 1084A is unchanged from before it was originally scrambled by MSE operation 1075 in communication node N.sub.0,0 at time t.sub.1. The re-encryptions in communication nodes N.sub.0,1 and N.sub.0, however, have changed the ciphertext two times since it left communication node N.sub.0,0.

(448) The shared secrets used to perform static mixing and scrambling and dynamic encryption and to reverse the process require two times or statestime t.sub.1 and corresponding state 991 used for the static mixing and scrambling in server 1011 and needed for unscrambling and splitting in the final DUS operation 1076 in server 1016, and the dynamic time and the corresponding state used by the last communication node to execute each of the re-encryption operations 1077 in servers 1012-1015, a state that varies dynamically and constantly as the data packet traverses the packet-switched communication network. In the final step, communication is completed by communication node N.sub.0,f, hosted on server 1016, which performs a DUS operation 1045, decrypting, unscrambling and splitting (un-mixing) the incoming data packet to reproduce plaintext outputs 1055 and 1056, the same data sent across the network starting at time t.sub.0.

(449) Since the packet is encrypted in node N.sub.0,0, re-encrypted as it passes through each of nodes N.sub.0,1 . . . N.sub.0,f-1, and decrypted in node N.sub.0,f, even though the data was mixed and scrambled only once, the opportunity for intercepting and interpreting the data packets being communicated is extremely complex and provides little time for hacking. Moreover, the mixing of multiple sources of data as described previously in this application, further confounds outsider attempts at hacking and cyber-piracy because the interloper has no idea what the various pieces of data are, where they came from, or where they are headedin essence lacking both detail and context in the nature of the data packet.

(450) Another method to manage data packet content during transport is to return to normal on every single hop. In this method illustrated in FIG. 66C, with the exception the gateway nodes, every node performs the sequential operation of DUS operation 1076 followed immediately by MSE operation 1075, in essence completely rebuilding the data packet for transport on every hop. As shown, incoming data packets 1055 and 1056 are first mixed by node N.sub.0,0 at time t.sub.1 using state 991 resulting in ciphertext 10802Z corresponding to plaintext 1080Y. Ciphertext 1080Z is then sent to node N.sub.0,1 where DUS operation 1076 identifies the incoming packet was created using state 991 corresponding to time t.sub.1 and as shown in detail in FIG. 66D sequentially decrypts it, converting incoming ciphertext 1080Z into plaintext 1080Y. Plaintext 1080Y is then unscrambled and split (i.e. un-mixed) thereby recovering original data packets 1055 and 1056.

(451) In preparation for the next network hop, the two original data packets are once again mixed and scrambled, this time using algorithms selected at the time t.sub.2 corresponding to state 992 resulting in plaintext 1080A which is subsequently encrypted to produce ciphertext 1080B ready to be sent to node N.sub.0,1. Using this method the incoming data packets are returned to the initial normal state each time they enter a node and depart in a completely new refreshed condition corresponding to present state. In this method each node only needs to know the state of the incoming packet and does not require knowledge of any prior states used during data transport.

(452) Mixing & Splitting Operations

(453) The process of mixing and splitting packets to combine and separate data of different types shown previously in FIG. 60A and FIG. 60B illustrates fixed-length packets obeying the principle of conservation of data segments where the total length of the long data packet 1054 has the same number of data segments as the sum of the shorter data packets 1055 and 1056 created from it. In essence, conservation of data segments means during successive mixing and splitting operations, data segments are neither created nor destroyed. This simple principle is problematic in communication because the quantity of real-time data may be sparse, unable to fill even one complete packet.

(454) In the opposite extreme, where a network may be heavily congested, a server may be unable to accept a long packet without imposing long propagation delays resulting in high latency. For this and other reasons, the dynamic mixing and splitting of data packets in accordance with the disclosed invention provides a means to manage, combine and separate data packets of varying length, controlling both the length and number of data packet inputs as well as the number and length of data packet outputs. The use of variable length packets containing content directed to different destinations further confounds hackers, conferring an added degree of security to the network. As shown in FIG. 67A, the parse operation 1087, and the junk operation 1088, for junk insertions and deletions, are conjunctively used to manage and control data packet length in mixed data packets, applicable for either single-output or multi-output mixing operations.

(455) FIG. 67A illustrates an example of single-output packet mixing where multiple inputs of varying length, in the example shown as 4-data segment packets 1090A and 1090C, and 3-data segment packet 1090B, are mixed using mixing operation 1086 to produce one long data packet 1091. The mixing operation 1086 is selected from a list of mixing algorithms 1085 in accordance with the current time or state 920 when the mixing occurs including the use of numeric seed 929 as generated by seed generator 921. During mixing operation 1086, junk operation 1088 inserts junk data segments into data packet output 1091 in accordance with the algorithm selected.

(456) After mixing, long data packet 1091, or alternatively sub-packets resulting from parsing operation 1092, may either be stored locally, e.g. waiting for other data packets to arrive, or may be sent on to other nodes in the communication network. Before storage or routing each packet or sub-packet is tagged with a header or sub-header identifying the packet. The tag is critical to recognize an incoming packet so that it may be processed according to instructions received previously as to what to with its data, including how to mix, scramble, encrypt or split, unscramble, and decrypt the data packet's content. The use of data packet headers and sub-headers to identify and tag data packets is described in greater detail later in this application.

(457) So in addition to confounding cyber-attackers, another role of parsing, junk, and de-junk operations is to manage the length of data packet. For example, if the resulting long data packet 1091 is too long, then in accordance with a selected algorithm, the parse operation 1087 breaks the long data packet output 1091 into shorter pieces. The length of the shorter pieces may be prescribed by the selected algorithm, e.g. cut the merged long packet at regular intervals 1092 of n sub-packets. The desired packet length can be decided a priori or can be based on a network condition, e.g. the maximum acceptable length may be calculated based on network delays. For instance, if the propagation delay ?t.sub.prop between two nodes exceeds a certain value, then the data packet will be parsed to make it smaller, e.g. where long data packet 1091 is broken up at regular intervals by parsing operation 1092 into n sub-packets.

(458) Regardless as to how the long packet is parsed, the multiple-output mixing operation produces multiple data packet outputs, e.g. data packets 1093A, 1093B, and 1093C, as shown in FIG. 67B. In the process as shown, junk data may be inserted into the sub-packets to produce sub-packets of controlled or fixed lengths. Each segment of a data packet or sub-packet, e.g. 1A, 1B, 1C, etc., is identified not by its value or content, but by its slot position in the packet. For example long data packet 1091 contains 18 data slots with data present in slots 1, 4, 7, 8, 9, 11, 12, 13, 15, and 17, while sub-packet 1093A is only 6 slots long, containing actual data content or audio in the 1.sup.st and 4.sup.th slots

(459) For convenience sake, the multiple-input single-output (MISO) mixing operation is symbolically represented herein by symbol 1089 while the multiple-input multiple-output (MIMO) mixing operation is symbolically represented by symbol 1094, similar to the earlier, more idealized example shown in FIG. 60A. In accordance with the invention disclosed herein, multiple-input single-output mixing 1089 is useful for secure last-mile connections while multiple-input multiple-output mixing 1094 is useful in realizing multi-path and meshed routing networks described later in the application. In the taxonomy of disclosed SDNP network elements and operations, MISO mixing operation 1089 may be considered a special case of MIMO mixing operation 1094.

(460) The inverse function to multiple-input single-output or MISO mixing is single-input multiple-output or SIMO splitting. In one embodiment, shown in FIG. 67C, a single long data packet 1091 is divided by splitting operation 1100 into multiple data sub-packets 1103A, 1103B, and 1103C which may comprise sub-packets of fixed or varying length. In the example shown, sub-packet 1103A contains 4 data slots while sub-packets 1103B and 1103C each contain only 3 slots.

(461) In a second embodiment, shown in FIG. 67D, a single long data packet 1091 is divided by splitting operation 1105 into multiple sub=packets 1108A, 1108B, and 1108C of identical, fixed lengths using junk data segments as filler when inadequate data is present to fill an entire data packet. In both examples, the time or state 920 and numeric seed 929 used when the incoming data packets were created are required to select a mixing algorithm from table 1085 and to set parameters needed to executing splitting operations 1100 and 1105. Although mixing algorithm table 1085 references the term mixing, the same algorithm table is used to identify and select the inverse function needed for performing splitting, i.e. mixing algorithm table 1085 contains the information needed both for mixing data packets and for splitting data packets. Because the two functions involve the same steps performed in reverse order, table 1085 could also be renamed as mixing/splitting algorithms table 1085. For clarity's sake however, the table is labeled only by the function and not by its inverse function. The methods used to perform data packet mixing and splitting are algorithmic, and in many ways similar to the scrambling algorithms described previously except that they generally involve more than one data packet as input or output. One exceptional case where mixing or splitting operations may be performed on a single data packet is during the insertion or removal of junk data.

(462) FIG. 67E illustrates one specific mixing algorithm mixing three incoming data packets 1090A labeled Sub-packet A, 1090B labeled Sub-packet B, and 1090C labeled Sub-packet C, into one long data packet 1091, then parsing long data packet 1091 into three different outgoing sub-packets packets 1090D labeled Sub-packet D, 1090E labeled Sub-packet E, and 1090F labeled Sub-packet F. As represented graphically, mixing operation 1094 remaps the data content from the slots of the incoming data packets into the long packet and well as inserting junk data into some intervening slots. For example as shown, the 3.sup.rd slot of sub-packet 1090A containing data segment 1C is moved into the 11.sup.th slot of long data packet 1091, the 3.sup.nd slot of sub-packet 1090B containing data segment 2F is moved into the 17.sup.th slot of long data packet 1091, and the 2.sup.nd slot of sub-packet 1090C containing data segment 3D is moved into the 12.sup.th slot of long data packet 1091. The complete mixing algorithm therefore comprises a substitution table as shown by example here below:

(463) TABLE-US-00006 Long Packet Incoming Incoming Data Contained Slot # Sub-packet # Sub-packet Slot # In Slot Slot 1 Sub-packet A Slot 1 1A Slot 2 Junk Data Inserted Slot 3 Junk Data Inserted Slot 4 Sub-packet A Slot 2 1B Slot 5 Junk Data Inserted Slot 6 Junk Data Inserted Slot 7 Sub-packet A Slot 3 1C Slot 8 Sub-packet B Slot 1 2C Slot 9 Sub-packet C Slot 1 3C Slot 10 Junk Data Inserted Slot 11 Sub-packet B Slot 2 2D Slot 12 Sub-packet C Slot 2 3D Slot 13 Sub-packet A Slot 4 1E Slot 14 Junk Data Inserted Slot 15 Sub-packet C Slot 3 3E Slot 16 Junk Data Inserted Slot 17 Sub-packet B Slot 3 2F Slot 18 Sub-packet C Slot 4 Junk

(464) So in general the function of the mixing operation is to define which slot in the in the mixed packet or long packet the incoming data is inserted, and to define which slots of the mixed packet contain junk.

(465) The table representation of the algorithm is exemplary to illustrate that any remapping of incoming data sub-packets into a long data packet is possible. As part of mixing operation 1094, parsing operation 1087 is next performed, cutting 1092 long data packet 1091 into three equal length pieces to create outgoing sub-packets 1093D, 1093E and 1093F, labeled correspondingly as Sub-packet D, Sub-packet E, and Sub-packet F.

(466) FIG. 67F illustrates an algorithm performing the splitting or un-mixing operation 1101 starting with three equal length sub-packets 1093D. 1093E, and 1093F resulting from previous parsing operation 1087, and remapping the data to create new sub-packets 1103A, 1103B, and 1103C of differing length as detailed in the table below. The purpose of the parsing operation is to break up a long packet into various pieces of smaller size or of shorter duration for local storage, or to serialize the data for data transmission.

(467) TABLE-US-00007 Data Incoming Incoming Split Output Split Output Contained Sub-packet Slot # Sub-packet Slot # In Slot Sub-packet D Slot 1 Sub-packet G Slot 1 1A Slot 2 Junk data removed Slot 3 Junk data removed Slot 4 Sub-packet G Slot 2 1B Slot 5 Junk data removed Slot 6 Junk data removed Sub-packet E Slot 1 Sub-packet G Slot 3 1C Slot 2 Sub-packet H Slot 1 2C Slot 3 Sub-packet J Slot 1 3C Slot 4 Junk data removed Slot 5 Sub-packet H Slot 2 2D Slot 6 Sub-packet J Slot 2 3D Sub-packet F Slot 1 Sub-packet G Slot 4 1E Slot 2 Junk data removed Slot 3 Sub-packet J Slot 3 3E Slot 4 Junk data removed Slot 5 Sub-packet H Slot 3 2F Slot 6 Junk data removed

(468) As shown, sub-packet 1103A labeled as Sub-packet G comprises 4 slots, where slot 1 is filled with data segment 1A from slot 1 of sub-packet D corresponding to slot 1 of long packet 1091, slot 2 is filled with data segment 1B from slot 4 of sub-packet D corresponding to slot 4 of long packet 1091, slot 3 is filled with data segment 1C from slot 1 of sub-packet E corresponding to slot 7 of long packet 1091, and slot 4 is filled with data segment 1E from slot 1 of sub-packet E corresponding to slot 13 of long packet 1091. Similarly, sub-packet 1103B labeled Sub-packet H comprises three slots, the first containing data segment 2C from the 2.sup.nd slot of Sub-packet E, the second containing data segment 2D from the 5.sup.th slot of Sub-packet E, and the third containing data segment 2F from the 5.sup.th slot of Sub-packet F. Sub-packet 1103C also comprises three slots. In slot 1, data segment 3C comes from slot 6 of Sub-packet E. In slot 2, data segment 3D comes from slot 6 of Sub-packet E. In slot 3 of Sub-packet J, data segment 3E comes from slot 3 of Sub-packet F.

(469) As such a splitting algorithm defines (a) how many split sub-packets there will be, (b) how many slots there will be in each split sub-packet, (c) into which slot of the split sub-packets the data of the long packet will go (d) which slots will be removed because they contain junk data, and (e) if new slots containing junk data are introduced, possibly to facilitate generating a specific length sub-packet. In cases where a splitting operation that follows a mixing operation, the number of sub-packets in the split packets has to equal the number of sub-packets in the packets before they are mixed unless junk data is removed or inserted.

(470) The roles of the disclosed mixing and splitting operations made in accordance with this invention may be adapted to implement fragmented data transport through any network with the caveat that all the nodes in the network know what sequence of operations is to be performed. In single route transport such as shown previously in FIG. 61B, the data packets 1055 and 1056 represent different conversations or communiqu?s from different callers or sources. Once merged, the long data packet, or parsed versions thereof are ready for transport through the network. Such a function can be considered a multiple-in single-out communication or MISO node.

(471) The original data packets are recovered by the inverse function, a single-in multiple-output or SIMO communication node, performing splitting. If the data packets in single-route communication have reached their final destination, they long packet data is split for the last time and the junk is removed to reconstitute the original data packet. The mixed data does not necessarily need to be the same data types. For example, one caller could be talking on the phone and sending text messages simultaneously, thereby generating or receiving two different data streams concurrently. If, however, the split data packets are intended continue routing onward in the network in an unmixed stated, junk data is included in the data packets to make data sniffing unusable.

(472) In the transport of homogeneous data, security is achieved primarily through scrambling shown in FIG. 64, or through the combination of scrambling and encryption as shown in FIG. 66A. The combination of mixing followed by scrambling used in both examples is further elaborated in the exemplary illustration of FIG. 67G where mixing operation 1094 mixes incoming data sub-packets 1090A, 1090B and 1090C to form unscrambled long data packet 1091. Scrambling operation 926, then in this example performs a linear phase shift by one data slot to the right, e.g. where the data 1A in slot 1 of the unscrambled packet moves to slot 2 in scrambled packet, the data 1C is slot 7 move to slot 8 in the scrambled package and so on, to create scrambled long data packet 1107.

(473) Parsing operation 1087 then cuts scrambled long data packet 1107 along cut lines 1092 after the 6.sup.th and the 12.sup.th slots to produce outputted sub-packets 1093G, 1093H, and 1093J. The consequence of the phase shift not only affects the position of data in the outputted sub-packets but it actually alters the packets' content. For example, when data segment 3D in slot position 12 in the unscrambled long data packet 1107 moves to position 13 after scrambling, parsing operation 1087 located in cut line 1092 after the 12.sup.th slot, naturally dislocates the data from data sub-packet 1093H to 1093J, as evidenced by a comparison of sub-packet 1093H with its new sequence of data segments J-1C-2C-3C-J-2D (where J indicates junk data) against sub-packet 1093E in FIG. 67E having the sequence of data segments 1C-2C-3C-J-2D-3D.

(474) FIG. 67H illustrates combining an algorithmic mixing, i.e. a mapping incoming data from sub-packets to form a long data packet, with a subsequent scrambling algorithm can be reproduced identically by merging the mixing and scrambling operations into a single step, just by changing the mapping algorithm. The hybrid mixing and scrambling operation 1094A is identical to the prior mixing algorithm except it dislocates the data by one position to the right in the long data packet 1107 during mapping. For example, data segment 1A in sub-packet 1090A is mapped into slot 2 of long data packet 1107 rather than into slot 1, data segment 3D in sub-packet 1090C is mapped into slot 13 of long data packet 1107 rather than into slot 12. The resulting outputted sub-packets 1093G, 1093H, and 1093J are identical to the sub-packets output using the sequence of mixing followed by scrambling shown in FIG. 67G. In essence, a mix then scramble algorithm represents another mixing algorithm. Because there is no difference in the resulting output, throughout the text, this disclosure will continue to identify separate mixing and scrambling operations with the understanding that the two numeric processes can be merged. Similarly, it is understood that the inverse process unscrambling and then splitting a data packet can be replaced by a single combined operation performing both unscrambling and splitting in a single step.

(475) In single route data transport, data packets cannot take parallel paths, but must instead travel in serial fashion across a single path between media servers or between a client's device and the cloud gateway, i.e. data transport over the last mile. Before the data sub-packets can be sent onto the network, they must be tagged with one or more headers to identify the packet so that the target communication node can be instructed what to do with the incoming packet. Although the formatting and information contained in these headers is described in greater detail later in the disclosure, for clarity's sake a simplified realization of packet tagging is shown in FIG. 67I. As shown, a series of data packets 1099A, 1099B, 1099C, and 1099Z arrive in sequence in the communication node. Each data packet includes a header such as 1102A, and its corresponding data, e.g. 1090A.

(476) As the data packets arrive at the node, operation 1600 separates the header from the data for processing. As shown for the first incoming packet 1099A, header 1102A labeled Hdr A is separated from data packet 1099A, then fed into tag reader operation 1602 which determines whether the communication node has received any instructions bearing on packet 1099A. If it has not received any instructions relating to packet 1099A, the corresponding data is discarded. This is shown for example by sub-packet 1092, labeled sub-packet Z, which contains data from conversations 6, 7, 8, 9 unrelated to any of the instructions received by the communications node. If, however, the data packet is expected, i.e., its tag matches an instruction previously received by the communication node from another server, then the recognized data packets, in this case sub-packets 1090A, 1090B and 1090C, are sent to mixing operation 1089. The proper algorithm previously selected for the incoming data packets is then loaded from mixing algorithm table 1050 into mixing operation 1089. In other words, the communication node has previously been instructed that when it receives the three packets identified by Hdr A, Hdr B and Hdr C, respectively, it is to mix the three packets in accordance with a particular mixing algorithm in table 1050. As noted above, this mixing algorithm may include a scrambling operation.

(477) In accordance with this disclosure, mixing operation 1059 then outputs data sub-packet 1093D, 1093E and 1093F in sequence, each of which are tagged with a new identifying header, i.e. Hdr D, Hdr E, and Hdr F to product data packets 1099D, 1099E, and 1099F ready for transport to the next communication node in the network. In single route communications these data packets are sent serially along the same route to their target destination. While the flow chart represents how the tags are used to identify packets for mixing, the tag identification method is identical for executing specific scrambling and encryption operations, and their inverse functions decrypting, unscrambling, and splitting.

(478) The mixing and splitting operations can be applied to multi-route and meshed transport described next using multiple output mixing and splitting operations. The various outputs represented by outward facing arrows in SIMO splitting symbol 1101 in FIG. 67F may be used to direct data packets across a network in different directions, paths, and routes. The instructions received by the communication node specify the tag to be applied as a header to each of the split packets as well as the identity of the node to which each of the split packets is to be sent. The recipient nodes are also instructed to expect the packets. Similarly, multiple input multiple output mixing operation 1094 shown in FIG. 67B may be applied to multiple route communication. As shown later in this application, MISO and M IMO data packet mixing and SIMO data packet splitting represent key elements in realizing multiroute and meshed routing. Even in the absence of packet scrambling and encryption, multipath and meshed data packet routing greatly diminishes the risk of meaningful data interception by cyber-pirates, packet sniffing, and man-in-the middle attacks on the network because no one communication node carries the entire conversation, or receives, or transmits any data set in its entirety. For illustrative purposes, the number of sub-packets shown in the disclosed figures is for illustrative purposes only. The actual number of packets communicated may comprise tens, hundreds or even thousands of sub-packets.

(479) Packet Routing

(480) As illustrated throughout the application thus far, a single path carries the serial stream of data packets used in packet-switched based network communication such as the Internet. Although this path may vary over time, intercepting the data stream by packet sniffing would, at least for some time interval, provide a cyber-pirate with complete data packets of coherent serial information. Without scrambling and encryption used in the SDNP communication disclosed in accordance with this invention, any sequence of data packets once intercepted, could easily be interpreted in any man-in-middle attack enabling effective and repeated cyber-assaults.

(481) Such single-route communication is the basis of Internet, VoIP, and OTT communication, and one reason Internet-based communication today is very insecure. While the successive packets sent may take different routes, near the source and destination communication nodes the chance that successive packets will follow the same route and transit through the same servers becomes increasingly likely because packet routing in the Internet is decided by service providers monopolizing a geography. Simply by tracing a packet's routing back toward its source, then packet sniffing near the source the chance of intercepting multiple packets of the same conversation and data stream increases dramatically because the communication is carried by only a single geographically based Internet service provider or ISP.

(482) As illustrated graphically in FIG. 68A, single-route communication 1110 represents serial data flow 1111 from a communication node N.sub.u,v to another communication node, in this case communication node N.sub.w,z. Although the path may vary over time, at any given instances, each coherent packet is serially transmitted on to the network transiting to its destination along one single path. As a matter of notation communication node N.sub.u,v designates a communication node hosted on server v located in network u, while communication node N.sub.w,z designates a communication node hosted on server z located in network w. Networks u and w represent the clouds owned operated by different ISPs. Although data packet routing in the middle of Internet routing may be carried by any number of ISPs, as the data packets near their destination they invariably become carried by a common ISP and network, making it easier to trace and packet-sniff successive data packets comprising the same conversation. This point is exemplified graphically in FIG. 68B where single-path communication 1111 occurs through a series of servers 1118 representing a single serial path communication network 1110. As shown, the communication starts from communication node N.sub.0,0 traveling successively through communication nodes N.sub.0,1 and N.sub.0,2 all in the same network numbered 0, till reaching communication node N.sub.2,3, carried by a different ISP over network 2. After that, the data is sent to the final nodes, both on network 1, i.e. communication nodes N.sub.1,4 and N.sub.1,f. So during transit the packet data first transmitted on to the Internet remains in server 0 before it has a chance to spread on to another ISP's network. Likewise, as the data packet approaches its destination, the likelihood that successive packets travel through the same nodes increases because they are all located on ISP network 1.

(483) In sharp contrast to single-path packet communication used for Internet OTT and VoIP communications, in one embodiment of SDNP communication in accordance with this invention, the content of data packets is not carried serially by coherent packets containing information from a common source or caller, but in fragmented form, dynamically mixing and remixing content emanating from multiple sources and callers, wherein said data agglomerates incomplete snippets of data, content, voice, video and files of dissimilar data types with junk data fillers. The advantage of the disclosed realization of data fragmentation and transport is that even unencrypted and unscrambled data packets are nearly impossible to interpret because they represent the combination of unrelated data and data types.

(484) As illustrated in FIG. 68A, SDNP communication of fragmented data packets is not serial as in single route transport 1110 but in parallel, using multiroute transport 1112 or meshed route transport 1114. In multiroute transport 1112 an array of two or more packet-switched communication nodes N.sub.u,v and N.sub.w,z establish and transport data concurrently over multiple routes 1113A, 1113B, 1113C, 1113D and 1113E. While five routes are shown, transport can occur in as few as two routes and up to a dozen or more if so needed. In is important to emphasize that this realization of a communication network does not represent simple redundant routing commonly employed by the Internet and packet-switched networks, i.e. where the same data may be sent on any one path or even on multiple paths simultaneously. Transmitting or communicating complete coherent packets of data redundantly over multiple channels actually increases the risk of being hacked because it affords a cyber-pirate multiple sources of identical data to sniff, analyze and crack.

(485) Instead, in SDNP communication, the information is fragmented, for example, with some portion of the data being sent across routes 1113A, 1113B, and 1113D with no data sent initially across route 1113C and 1113E and then at a later time, fragmented data split and combined differently and sent across routes 1113A, 1113C, and 1113E with no data being sent across route 1113B and 1113D. An example of multiroute transport 1112 is illustrated in FIG. 68C by the network comprising an array of communication servers 1118 arranged to establish multiple data paths between communicating communication nodes N.sub.0,0 and N.sub.f,f. As shown, the multipath transport occurs on four sets of interconnected servers representing networks 1 through 4. One data path, route 1113A, comprises communication nodes N.sub.1,1, N.sub.1,2, N.sub.1,3, and N.sub.1,4. A parallel data path, route 1113B, comprises communication nodes N.sub.2,1, N.sub.2,2, N.sub.2,3, and N.sub.2,4. Similarly, parallel data route 1113C comprises interconnected communication nodes N.sub.3,1, N.sub.3,2, N.sub.3,3, and N.sub.3,4 while route 1113D comprises interconnected communication nodes N.sub.4,1, N.sub.4,2, N.sub.4,3, and N.sub.4,4.

(486) In meshed route transport 1114, illustrated also in FIG. 68D, communication is sent along multiple interacting routes including the aforementioned routes 1113A, 1113B, 1113C, 1113D and 1113E as well as the cross-connections 1115A through 1115E between the routes 1113A through 113D. Together the connections form a mesh whereby data packets can travel by any combination of routes, and even be mixed or recombined dynamically with data packets being sent by other routes. In meshed transport 1114 the network comprises an array of communication servers 1118 arranged to establish meshed data paths between communicating communication nodes N.sub.0,0 and N.sub.f,f. As shown, the multipath transport occurs on interconnected servers with both horizontally and vertically oriented data paths. The horizontally oriented route 1113A comprises communication nodes N.sub.1,1, N.sub.1,2, N.sub.1,3, and N.sub.1,4, route 1113B, comprises communication nodes N.sub.2,1, N.sub.2,2, N.sub.2,3, and N.sub.2,4, route 1113C comprises interconnected communication nodes N.sub.3,1, N.sub.3,2, N.sub.3,3, and N.sub.3,4 and route 1113D comprises interconnected communication nodes N.sub.4,1, N.sub.4,2, N.sub.4,3, and N.sub.4,4. The vertically oriented route 1115A comprises communication nodes N.sub.1,1, N.sub.2,1, N.sub.3,1, and N.sub.4,1, route 1115B comprises communication nodes N.sub.1,2, N.sub.2,2, N.sub.2,3, and N.sub.4,2, route 1115C comprises interconnected communication nodes N.sub.1,3, N.sub.2,3, N.sub.3,3, and N.sub.4,3 and route 1115D comprises interconnected communication nodes N.sub.1,4, N.sub.2,4, N.sub.3,4, and N.sub.4,4. The network can further be augmented by diagonal interconnections 1119, as shown in FIG. 68E.

(487) Multiroute transport may be combined in various ways with scrambling and encryption. An example of multiroute transport with no scrambling is illustrated in FIG. 69, where a network of communication servers 1118 transports data packet 1055 from communication node N.sub.0,0 at time t.sub.0 to communication node N.sub.f,f at time t.sub.f. In transport 1112, communication node N.sub.0,0 performs splitting operation 1106 sending data segments 1C and 1E in data packet 1125A on data route 1113A, sending data segment 1B in data packet 1125B on data route 1113B, sending data segment 1D in data packet 1125C on data route 1113C, and sending data segments 1A and 1F in data packet 1125C on data route 1113D. The sub-packets may comprise a mix of data and unrelated sub-packets or junk data. Because the sub-packets are not scrambled, the sequence of data segments 1C and 1E in data packet 1125A remain in sequential order, even if other data segments may be inserted in between or before or after them. Finally, in communication node N.sub.f,f mixing operation 1089 reconstructs the original data packet at time t.sub.f. At all times to between time t.sub.0 and time t.sub.f, the contents of data packets 1125A through 1125D remain constant.

(488) A simple variant of the aforementioned multiroute transport with no scrambling is illustrated in FIG. 70, comprising multiroute transport with static scrambling, meaning incoming data packet 1055 is scrambled before being split and delivered over multiple routes in the network. Specifically, communication node N.sub.0,0 performs scrambling and splitting operation 1071 instead of just performing splitting operation 1106 shown in FIG. 69. The resulting scrambled mixed data packets 1126A through 1126D, like in the prior example, are static and time invariant remaining unchanged at all times to while they independently traverse the network upon paths 1113A through 1113D respectively, until they reach the final communication node N.sub.f,f where they are merged back together and unscrambled using unscrambling and mixing operation 1070 to recover original data packet 1055. Compared to the prior example of FIG. 69, the only major difference in the data packets 1126A-1126D of FIG. 70 is that the packets are scrambled, i.e. the data segments they contain are not in the original sequential order. For example, in data packet 1126A, data segment 1E occurs before 1B and in data packet 1126D, data segment 1D occurs before 1A. A disadvantage of static packet communication is that, while it is not subject to simple packet sniffing, it does afford a cyber-pirate unchanging data to analyze. Nonetheless, because the data present in any one data packet traveling on any one route is incomplete, fragmented, scrambled and mixed with other unrelated data sources and conversations, it is still significantly superior to OTT communication over the Internet.

(489) An improvement to static scrambling is to employ dynamic scrambling shown in FIG. 71A where repeated packet scrambling, i.e. US re-scrambling operation 1017, changes the data segment order in the data packet as a data packet traverses the network, meaning a comparison of any data packet traversing a given route changes over time. For example, regarding the data packet traversing route 1113A, in data packet 1126A at time t.sub.3 immediately after undergoing US re-scrambling operation 1017 in communication node N.sub.1,3, data segment 1E is located in the second time slot and precedes data segment 1B located in the fourth time slot. At time t.sub.4 after communication node N.sub.1,4 performs US re-scrambling operation 1017, data packet 1127A has changed with data segment 1B located before 1E successively located in time slots three and four. Comparing data packet 1126D to 1127D, the position of data segments 1D and 1A change but the order remains unchanged. This method employs the technique of dynamically scrambling every data segment in a data packet, not just the data from a specific source or conversation. It is possible to vary a packet's length immediately after it is unscrambled and before it is scrambled again, e.g. by inserting or deleting junk data. In the example shown, however, the packet lengths remains fixed, with only their sequence changing.

(490) As shown, the first communication node N.sub.0,0 performs scramble and split operation 1071, the last communication node N.sub.f,f performs mix and unscramble operation 1070, and all the intervening communication nodes perform US re-scrambling operation 1017. In each case, the unscrambling operation relies on the time or the state of the incoming packet, and the scrambling operation utilizes the time or state of the outgoing data packet. In parallel multi-route transport, splitting occurs only once in communication node N.sub.0,0 and mixing occurs only once, at the end of transport in communication node N.sub.f,f. Methodologically, this sequence can be categorized as scramble then split. In the embodiment of dynamic scrambling as shown in FIG. 71A, known herein as sequential or linear scrambling, no matter what the sequence, the prior operations must be undone in the inverse order in which they occurred, whereby the reordering of each data segments location in a data packet occurs algorithmically with no regard to what the content is or from whence it came. In this manner, the first communication nodes after splitting, namely communication nodes N.sub.1,1, N.sub.2,1, N.sub.3,1, and 4.sub.4,1 all perform the same unscrambling operation to undo the impact of the original scrambling of scramble-then-split operation 1071, returning each data segment containing data to its original location before re-scrambling it. In the splitting process, the location of a packet remains in the same position where it was located originally with the unused slots filled with junk data. For example if data segment 1B is moved to the fifth position in the packet by scramble and split operation 1118, after splitting the packet containing data segment 1B will retain it in the fifth position. Unscrambling the packet will move data segment 1B back to the second slot where it belongs even if all the other slots are filled with junk data. The dislocation of junk data is irrelevant since the junk data packets will be removed, i.e. de-junked later in the data recovery process anyway. Once the position of a specific data segment is restored to its original slot by an unscrambling operation, it may be scrambled again moving it to a new position. The combination of restoring a data segment to its original position and then scrambling anew into a new position, means the rescrambling process comprises unscrambling then scrambling, hence its name US rescrambling 1017.

(491) A simplified description of the previously detailed linear scramble then split method shown in FIG. 71B is contrasted to two other alternate embodiments of the disclosed invention, referred to herein as nested scramble then split and linear split then scramble. In the linear scramble then split method, successively and repeatedly scrambling and unscrambling every data packet refreshes the security of the data packet. As such, the scrambling first performed in scramble and split operation 1071 must be undone by US re-scrambling operation 1017 separately in each of the data paths, where the brackets symbolically represent multiple parallel paths or routes, meaning the time, state or numeric seed used to select and perform the pre-split scrambling operation in scramble and split operation 1071 is passed to the first communication node in every communication route so that unscrambling in US re-scrambling operation 1017 can be executed. Thereafter, each route separately scrambles and unscrambles the data packets traversing that route, where the US re-scrambling operation 1017 always employs the time, state, or numeric seed used to execute the last scrambling, then uses its current time or state to execute the new scrambling. In the last step, mix and unscramble operation 1070, the scrambled components are re-assembled in scrambled form and then finally unscrambled using the state or time when they were last scrambled to recover the original data.

(492) In the nested scramble & split example also shown in FIG. 71B, scramble then split operation 1071 first scrambles the data packet at an initial time or state and then after splitting the data into multiple routes, each data path independently performs a second scrambling operation 926 unrelated to the first, without ever undoing the first scrambling operation. Since a scrambling operation is performed on an already scrambled data packet, the scrambling can be considered as nested, i.e. one scrambling inside the other. In programming vernacular for nested objects or software code, the first scrambling as performed by scrambling and split operation 1071 comprises an outer scrambling loop while the second and all successive scrambling US re-scrambling operations 1017 represent an inner scrambling loop. This means the data traversing the network has been twice scrambled and must be unscrambled twice to recover the original the data. The final step of the inner scrambling loop comprises unscrambling operation 928, restoring each route's data packets into the same condition, i.e. the same data segment sequence, as immediately after packet splitting first occurred. The data packets are then reassembled into a single data packet and unscrambled using mix and unscramble operation 1070.

(493) The same concept of nested operations can be used in performing nested splitting and mixing operations as shown in FIG. 71C. Within a client's SDNP application 1335, various sources of data including video, text, voice, and data files can be mixed, serialized, inserted with junk data, scrambled then encrypted by MSE operation 1075. The security credentials including key 1030W and seed 929W can be exchanged from the sending client cell phone 32 directly to the receiving client tablet 33, without using media nodes carrying the content. For example, this information could be sent to the receiver using a separate signaling server network (described later) or alternatively, since the seeds and keys do not contain useful information for outsiders, such information could even be forwarded to the receiving client over the Internet. This first operation occurring in the client's device or application represents the beginning of the outer loop used to realize client security independent from the SDNP network.

(494) Once mixed, junked, scrambled and encrypted, the unreadable client ciphertext 1080W is next sent to the SDNP gateway server N.sub.0,0 where it is once again processed using different shared secrets with different algorithms, states, and network specific security credentials such as seed 929U and key 1030U in preparation for transport through the SDNP cloud. This inner loop facilitates cloud-server security and is completely independent from the client's security loop. As part of the gateway SSE operation 1140 for incoming data packets, the data packet may be scrambled a second time, split into different sub-packets and encrypted into ciphertext 1080U and 1080V for multiroute or meshed transport.

(495) Eventually the multiple sub-packets arrive at the destination gateway N.sub.f,f where they are processed by DMU operation 1141 to undo the effect of the initial gateway's splitting operation, i.e. DMU operation 1141 undoes the effects of SSE operation 1140 completing the inner security loop's function. As such, gateway N.sub.f,f undoes all network related security measures implemented by incoming gateway N.sub.0,0 and restores the original file, in this case client ciphertext 1080W to the same condition as when as it entered the SDNP cloud.

(496) But because this data packet was already mixed, scrambled and encrypted, the data packet comprising ciphertext 1080W exiting the SDNP gateway and being sent to the receiving client is still encrypted, un-interpretable by anyone but the receiving client's application 1335. The restored ciphertext once delivered to the client is then decrypted and unscrambled by DUS operation 1076 in accordance with the sending client's state when it was created at time t.sub.0 and finally split to recover various sources of data components including video, text, voice, and data files, completing the outer security loop.

(497) So to thwart network subversion, i.e. where a cybercriminal posing as a SDNP network operator attempts to defeat the SDNP security from inside the network, the outer loop security credentials, i.e. shared secrets, seeds, keys, security zones, etc. are intentionally made different than that of the inner security loop.

(498) In another embodiment of this invention also shown in FIG. 71B, in the process of linear split then scramble data is first split, then separately scrambled on each data route. Data splitting operation 1057 is followed by independent scrambling operation 926 realized and executed on a route-by-route basis. Once scrambled, the data packets traversing each route are successively re-scrambled by US re-scrambling operations 1017 where the incoming packet is unscrambling using the same time, state, or numeric seeds used by scrambling operation 926 to create it. Thereafter, each route separately scrambles and unscrambles the data packets traversing that route, where the US re-scrambling operation 1017 always employs the time, state, or numeric seed used to execute the last scrambling, then uses its current time or state to execute the new scrambling. The final step comprises unscrambling operation 928, restoring each route's data packets into the same condition, i.e. the same data segment sequence, as immediately after packet splitting first occurred. The data packets are then reassembled into a single unscrambled data packet using mixing operation 1061.

(499) Regardless of the sequence of mixing and scrambling employed, the processed data packets can also be subjected to static or dynamic encryption to facilitate an added degree of security. One example of this combination is shown in FIG. 72 comprising a method described as static scrambling then splitting and dynamic encryption comprising the following steps: 1. Starting with input unscrambled plaintext at time t.sub.0 2. Scramble unscrambled plaintext 1055 using static packet scrambling 926 at time t.sub.1 3. Splitting scrambled plaintext 1130 into multiple split data packets 1131A, 1133A and others using splitting operation 1106 at time t.sub.2. 4. Directing split data packets 1131A, 1133A and others on multiple dissimilar non-overlapping parallel routes at time t.sub.3 (note that only two of these parallel routes are shown in detail in FIG. 72) 5. Independently encrypting each data packet 1131A, 1133A and others at time t.sub.4 using encryption 1026 including encryption keys and numeric seeds corresponding to state 994, resulting in ciphertext 1132A, 1134A, and others 6. Independently decrypting each data packet 1132A, 1134A, and others with state 994 information, including shared secrets, keys, numeric seeds, etc. using decryption 1032 resulting in unencrypted plaintext 1131B, 1133B, and others 7. Independently re-encrypting unencrypted plaintext 1131B, 1133B and others using encryption 1026 at time t.sub.6 using encryption keys and numeric seeds corresponding to state 996 resulting in ciphertext 1132B, 1134B, and others 8. Independently decrypting each data packet 1132B, 1134B, and others with state 996 information, including shared secrets, keys, numeric seeds, etc. using decryption 1032 resulting in unencrypted plaintext 1131C, 1133C and others 9. Mixing unencrypted plaintext 1131C, 1133C and other at time t.sub.7 using mixing operation 1089 to produce scrambled plaintext 1130 10. Unscrambling scrambled plaintext 1130 at time t.sub.8 using state 991 corresponding to time t.sub.1 when the scrambling first occurred to recover the original unscrambled plaintext 1055.
In the example shown, the initial data packet processing comprises the sequential application of scrambling, splitting and encryption shown as operation 1140. The final operation comprises decryption, mixing and unscrambling shown by operation 1141. All intermediate steps comprise re-encryption, which itself comprises both decryption and encryption.

(500) One example of the use of this method in multiroute transport is illustrated in FIG. 73 where communication node N.sub.0,0 performs scrambling, splitting, encryption operation 1140A and communication node N.sub.f,f performs decryption, mixing and unscrambling operation 1141A, while all intermediate nodes perform re-encryption operation 1077. In multiroute transport in accordance with this invention, various combinations of static and dynamic scrambling and static and dynamic encryption are possible.

(501) As an option to scramble, split and encrypt, in an alternate embodiment of this invention, data packets may be split then scrambled and encrypted using the split, scramble, encrypt operation 1140B shown in FIG. 74. In this method, the incoming data packet is first split in operation 1106. Subsequently, the data packets in each route are independently scrambled in operation 926 and encrypted in operation 1026. The resulting data packets may then independently be repetitively unencrypted then re-encrypted using re-encryption operation 1077 or may be unencrypted, unscrambled, re-scrambled, and re-encrypted using DUSE re-packet operation 1045.

(502) In contrast to meshed routing described below, in the multi-route transport as exemplified in FIG. 69 through FIG. 73, each data packet traversing the network is processed only once by a given communication node and no communication node processes more than one data packet carrying related data or common conversation, i.e. data routes 1113A, 1113B, 1113C and 1113D are separate, distinct, and non-overlapping.

(503) Meshed Routing

(504) Returning again to FIG. 68A, meshed packet routing and transport disclosed herein is similar to parallel multiroute transport except that data packets traversing the network in different paths may cross paths in the same servers. In static meshed routing as disclosed herein, these data packets pass through a common server without interacting, as though the other conversation or communication data did not even exist. In dynamic meshed routing, however, upon entering a communication node, the data packets may interact with the other data packets concurrently present in the same server.

(505) Using the previously described method of splitting and mixing, groups of data segments may be separated or removed from one data packet, combined with or merged into another data packet, and sent on a trajectory to a destination different from the one from whence it came. Meshed routing in accordance with this invention may utilize variable-length or fixed-length data packets. In variable-length packets, the number of data segments comprising a data packet may vary based on the amount of traffic traversing a given communication node. In fixed-length meshed transport, the number of data segments used to constitute a full data packet is fixed at some constant number or alternatively at some number of data segments adjusted in quantized integer increments.

(506) The main difference between the use of variable- and fixed-length data packets is in the use of junk data as packet fillers. In variable length-data packets, the use of junk data is purely optional, mainly based on security considerations, or to exercise unused paths in order to monitor network propagation delays. The use of junk data in fixed-length data packets is mandatory because there is no way to insure that the proper number of data segments is available to fill the packets departing the communication node. As such, junk data is necessarily used constantly and continuously as packet filler to insure each data packet exiting the server is filled to the specified length before being sent onward across the network.

(507) An example of static meshed data transport across communication network 1112 is illustrated in FIG. 75, where data packet 1055 is split by communication node N.sub.0,0 at time t.sub.0 into four packets of varying length, specifically data packet 1128A comprising data segment 1F, data packet 1128B comprising data segment 1C, data packet 1128C comprising data segments 1A and 1D, and data packet 1128D comprising data segments 1B and 1E. The data segments shown may be combined with other data segments from other data packets and conversations, also of variable length. Data segments from other conversations have been intentionally left out of the illustration for clarity's sake.

(508) During static transport the data packet's content, i.e. the data segments it contains, remains unchanged as it traverses the network. For example, data packet 1128A, comprising data segment 1F, traverses communication nodes in sequence from communication node N.sub.0,0 first to communication node N.sub.1,1 then on to communication nodes N.sub.2,1, N.sub.3,2, N.sub.3,3, N.sub.4,3, and N.sub.4,4, before finally being reassembled with packets 1128B, 1128C and 1128D in final communication node N.sub.f,f to recreate data packet 1055 at time t.sub.f. In similar fashion, data packet 1128C, comprising data segments 1A and 1D, traverses communication nodes in sequence from communication node N.sub.0,0 first to communication node N.sub.3,1 then on to communication node N.sub.2,3, and communication node N.sub.1,4, before finally being reassembled with packets 1128A, 1128B and 1128D in final communication node N.sub.f,f at time t.sub.f. During static meshed transport, multiple data packets pass through common servers without mixing or interacting. For example, data packets 1128A and 1128B both pass through communication node N.sub.2,1, data packets 1128B and 1128C both pass through communication node N.sub.2,3 and data packets 1128A and 1128D both pass through communication node N.sub.3,3 without disturbing one another, exchanging content, or swapping data segments.

(509) Since the data paths may be of different lengths and exhibit different propagation delays, some data packets may arrive at final communication node N.sub.f,f before others. In such instances, in accordance with this invention, the data packets must be held temporarily in communication node N.sub.f,f until the other related data packets arrive. And while the drawing shows that the final assembly and recovery of original data packet 1055 occurs in communication node N.sub.f,f, in practice the final packet reassembly, i.e. mixing, can occur in a device such as a desktop, notebook, cell phone, tablet, set top box, automobile, refrigerator, or other hardware device connected to the network. In other words, in regards to meshed transport, there is no distinction between a communication node and a device connected to a communication node, i.e. communication node N.sub.f,f could be considered a desktop computer instead of being a true high-capacity server. The connection of a device to the disclosed SDNP cloud, i.e. the last-mile connection, is discussed in further detail later in this application.

(510) The aforementioned static routing can be merged with any of the aforementioned SDNP methods as disclosed, including scrambling, encryption, or combinations thereof. For example, in FIG. 76, variable-length static meshed routing is combined with static scrambling. As shown, at time t.sub.1 unscrambled data packet 1055 is converted into scrambled plaintext data packet 1130, which is then split by communication node N.sub.0,0 and then the split packets mixed with junk data are sent across network 1112. Routing is similar to the prior example except that the data segments are intentionally disordered and mixed with junk data segments before routing. For example, data packet 1132C comprising data segments 1D and 1A separated by a intervening junk packet traverses communication nodes in sequence from communication node N.sub.0,0 first to communication node N.sub.3,1 then on to communication nodes N.sub.2,3, N.sub.3,2, and N.sub.1,4, before finally being reassembled with packets 1128A, 1128B and 1128D in final communication node N.sub.f,f to recreate data packet 1055 at time t.sub.f. In similar fashion, data packet 1132D comprising data packets 1E and 1B in inverse order traverses communication nodes in sequence from communication node N.sub.0,0 first to communication node N.sub.4,1 then on to communication nodes N.sub.4,2, N.sub.3,3, and N.sub.2,4, before finally being reassembled with packets 1128A, 1128B and 1128C in final communication node N.sub.f,f at time t.sub.f. In this final node, during mixing a de-junk operation is performed removing junk data to produce original scrambled data 1130. After unscrambling, the original data 1055 is recovered.

(511) To implement dynamic meshed transport in accordance with the invention disclosed herein, packets must be processed to change their content and direction within each communication node processing a packet. This process involves merging incoming data packets into a single long data packet, or alternatively utilizing a data buffer containing the same sub-packets as if the long data packet was created, then splitting these packets into different combinations and sending those packets to different destinations. The process may employ variable- or fixed-length packets as described previously. FIG. 77A shows elements of a SDNP communication network including communication nodes N.sub.a,b, N.sub.a,d, N.sub.a,f, and N.sub.a,h, all in network A sending corresponding variable length data packets 1128B, 1128D, 1128F and 1128H respectively to communication node N.sub.a,j that performs mixing operation 1089, assembling the packets into either short or long data packet 1055. Packet 1055 is then split, using split operation 1106, in communication node N.sub.a,j to create new data variable length data packets 1135N, 1135Q, and 1135S are sent to communication nodes N.sub.a,n, N.sub.a,q and N.sub.a,s, respectively. No data or junk data 1135V is sent to communication node N.sub.a,v. In each case, the length of the incoming packets is variable and the packets may contain junk data or data from other communications, conversations or communiqu?s not shown. As shown, the combination of mixing operation 1089 and splitting operation 1106 is performed by communication node N.sub.a,j, to facilitate dynamic meshed routing utilizing data mixing and splitting operation 1148. In a manner explained below, the newly split packets 1135N, 1135Q, 1135S and 1135V (assuming the latter contains junk data) and their routing are determined either by dynamic instructions sent to communication node N.sub.a,j by the SDNP network or by using a predefined algorithm or instruction set in the absence of such incoming command and control signals.

(512) In order to process the incoming packets, i.e. mix them, then split them into new packets of different combinations, node N.sub.a,j must receive instructions before the data arrives telling the node how to identify the data packets to be processed and what to do with them. These instructions may comprise fixed algorithms stored locally as a shared secret, i.e. a predefined algorithm or instruction set, or the sequence can be defined explicitly in a command and control dynamic instruction sent to the node in advance, of the data, ideally from another server controlling routing but not on a server carrying data. If the instructions of what to do to the incoming data are embedded within the data stream itself, i.e. part of the media or content, the routing is referred to herein as single-channel communication. If the data packet routing is decided by another server and communicated to the media server, the data routing is referred to as dual-channel (or possibly tri-channel) communication. The operational details of single- and dual/tri-channel communication are described in greater detail later in the application.

(513) Regardless of how the instructions are delivered, the media node must recognize the incoming data packets to know the instruction that pertains to a specific data packet. This identifying information or tag operates like a zip code or a courier package routing bar code to identify the packets of interest. The incoming data packets 1128B, 1128D, 1128F, and 1128H shown in FIG. 77A, however, only represent the audio or textual content of the packet, not the identifying tags. The process of using tagged data present within a packet header to identify each specific data packet and to determine how incoming data packets are to be mixed was described previously for FIG. 67I. Specific examples of tag and routing information contained within the data packets are discussed further later in the application. Once node N.sub.a,j has been informed what data packets to look for and what algorithm to use in mixing operation 1089 and splitting operation 1106, the data can be processed.

(514) The fixed-length data packet equivalent of the same operation is shown in FIG. 77B, where communication nodes N.sub.a,b, N.sub.a,d, N.sub.a,f, and N.sub.a,h, all in network A send corresponding fixed-length data packets 1150B, 1150D, 1150F and 1150H, respectively, to communication node N.sub.a,j that in turn performs mix and split operation 1148 to create new fixed length data packets 1151N, 1151Q, and 1151S, sent to communication nodes N.sub.a,n, N.sub.a,q and N.sub.a,s respectively. No data or junk data 1151V is sent to communication node N.sub.a,v. In each case, the length of the incoming packets is fixed and necessarily contains junk data fillers or data from other conversation of communiqu?s not shown to maintain data packets of fixed lengths, i.e. containing a prescribed number of data segments.

(515) The interconnection of servers as described in network Layer-3 protocol comprises a myriad of connections, each communication node output connected to the input of another communication node. For example, as shown in FIG. 77C, the outputs of communication node N.sub.a,b performing mixing and splitting operation 1149B are connected to the inputs of communication nodes N.sub.a,j, N.sub.a,q, N.sub.a,v, and N.sub.a,f. The outputs of communication node N.sub.a,q performing mixing and splitting operation 1149Q are connected to the inputs of communication nodes N.sub.a,b, N.sub.a,j and N.sub.a,f and another communication node not shown in the illustration. In similar fashion, the outputs of communication node N.sub.a,f performing mix and splitting operation 1149F are connected to the inputs of communication nodes N.sub.a,q, N.sub.a,j and N.sub.a,v, and another communication node not shown in the illustration; the outputs of communication node N.sub.a,j, performing mixing and splitting operation 1149J, are connected to the inputs of communication nodes N.sub.a,q, and N.sub.a,v along with other communication nodes not shown in the illustration; and the outputs of communication node N.sub.a,v performing mixing and splitting operation 1149V are connected to the inputs of communication nodes N.sub.a,f, and other communication nodes not shown in the illustration.

(516) Since the output-to-input connections are network descriptions and not simply PHY layer 1 connections or circuits, these network connections between devices can be established or dissolved on an ad hoc basis for any device having a Layer 1 PHY connection and a Layer 2 data link to the aforementioned network or cloud. Also, since the connections represent possible network communication paths and not fixed, permanent electrical circuits, the fact that the output of communication node N.sub.a,b is connected to input of communication node N.sub.a,q and the output of communication node N.sub.a,q is connected to input of communication node N.sub.a,b does not create feedback or a race condition as it would in electrical circuits.

(517) In fact, any computer electrically connected to the network can be added or removed as a communication node dynamically and on an ad hoc basis using software. Connecting a computer onto a network involves registering the communication node with the name server or any server performing the name server function. As described in the background section of this application, in the internet the name server is a network of computers identifying their electronic identity as an Internet address using IPv4 or IPv6 formats. The top-most Internet name server is the global DNS or domain name servers. Some computers do not use a real Internet address, but instead have an address assigned by a NAT or network address translator.

(518) In a similar manner, the disclosed secure dynamic network and protocol utilizes a name server function to keep track of every device in SDNP network. Whenever a SDNP communication node is launched, or in computer vernacular, whenever a SDNP node's software is booted up, the new device dynamically registers itself onto the network's name server so that other SDNP nodes know it is online and available for communication. In tri-channel communication, the SDNP name servers are separate from the servers used for command and control, i.e. the signaling servers, and from the media servers carrying the actual communication content. In single-channel communication, one set of servers must perform both the name server task as well as control routing and carry the content. Thus, the three types of SDNP systems described hereinsingle-channel, dual-channel and tri-channelare distinguished by the servers used to perform the transport, signaling and naming functions. In single-channel systems, the communication node servers perform all three functions; in dual-channel systems, the signaling and naming functions are separated from the transport function and are performed by signaling servers; and in tri-channel systems, the naming function is separated from the transport and signaling functions and is performed by the name servers. In practice, a given SDNP network need not be uniform but may be subdivided into portions that are single-channel, portions that are dual-channel, and portions that are tri-channel.

(519) Any new SDNP communication node coming online registers itself by informing the name server of its SDNP address. This address is not an Internet address, but an address known only by the SDNP network, and cannot be accessed through the Internet, because like a NAT address, the SDNP address is meaningless to the Internet, despite following the Internet protocol. As such, communication using the disclosed secure dynamic network and protocol represents anonymous communication because the IP addresses are unrecognizable on the Internet, and because only the last SDNP address and next SDNP address, i.e. the packet's next destination, are present within a given packet.

(520) An important embodiment of the SDNP network is its ability to modulate the total available bandwidth of the cloud automatically as traffic increases or declines within any given hour of the day. More SDNP communication nodes are automatically added into the network as traffic increases and dropped during slow minimizing network cost without compromising stability or performance.

(521) This feature means the bandwidth and expanse of the SDNP network disclosed herein can also be dynamically adjusted to minimize operating costs, i.e. not paying for unused compute cycles on an unutilized node, while being able to increase capability as demand requires it. The advantages of the software-implemented or soft-switch embodiment of the SDNP network sharply contrasts with the fixed hardware and high cost of hardware-implemented packet-switched communication networks still pervasive today. In the soft-switch realized network, any communication node loaded with the SDNP communication software and connected to the network or Internet can be added into the SDNP as needed, as shown in the network graph of FIG. 77D, where computer servers 1149D, 1149B, 1149F, 1149Q, 1149H, 1149N, 1149J, 1149S, and 1149V can be added as corresponding communication nodes N.sub.a,q, N.sub.a,d, N.sub.a,b, N.sub.a,f, N.sub.a,q, N.sub.a,h, N.sub.a,u, N.sub.a,j, N.sub.a,s, and N.sub.a,v, respectively as the need arises for traffic in the node or communication across its connections.

(522) So each link in the SDNP cloud can be viewed as an always-on physical connection of the Layer 1 PHY with corresponding a data link Layer 2, combined with a Layer 3 network connection that is established only when the SDNP launches, i.e. activates, a new communication node as needed. So the soft-switch based SDNP cloud itself is adaptive and dynamic, changing with demand. Unlike peer-to-peer networks where data is relayed through any device or computer, even of unknown bandwidth and reliability, each SDNP communication node is a prequalified device, loaded with the SDNP soft-switch software and fully authorized to join the SDNP cloud and carry data using its prescribed secure communication protocol, which comprises the informational content (such as a shared secret) plus the syntax, e.g. a specific format of header. Shared secrets describe algorithms, seed generators, scrambling methods, encryption methods, and mixing methods but do not stipulate the format of an entire SDNP data packet. Security settings, i.e. the settings being used at a particular time and for specific communications, are a type of shared secrets, but shared secrets also include the entire list of algorithms even ones not in use. Since the software is encrypted and the algorithm and shared secrets are processed dynamically, even in the event the SDNP code is hosted on a public cloud such as Amazon or Microsoft, the server operators have no means by which to monitor the content of data traffic on the SDNP communication node other than the total data volume being transported.

(523) As a natural extension of the dynamic network, new SDNP clients such as a cell phone, tablet, or notebook, also register automatically with the SDNP name server or gateway whenever they are turned on. So not only the SDNP cloud but the number of clients available for connection adjusts automatically, accurately reflecting the number of network connected and active users at any given time.

(524) Scrambled or Encrypted Meshed Routing

(525) To support dynamic autonomous capability, each SDNP communication node executes a prescribed combination of data mixing and splitting, scrambling and unscrambling, encryption and decryption concurrently to simultaneously support multiple conversations, communiqu?s and secure sessions. In the soft-switch embodiment of the SDNP network, all functions implemented and the sequence of these operations can be entirely configured through software-based instructions as defined through shared secrets, carried by the data packet, or defined by a parallel signal channel for command and control, separate and distinct from the SDNP communication nodes used for carrying media. While a large number of permutations and combinations are possible, the examples shown herein are intended to represent the flexibility of SDNP-based communication and not to limit the application of the various SDNP functions described to a specific sequence of data processing steps. For example scrambling can precede or follow mixing or splitting, encryption can occur first, last or in between, etc.

(526) One such operation, re-scrambled mixing and splitting operation 1155 shown in FIG. 78A performs a sequence of SDNP specific functions on multiple incoming data packets from communication nodes N.sub.a,b, N.sub.a,d, N.sub.a,f and N.sub.a,h comprising unscramble operation 928 performed on each incoming data packet, mixing and then splitting the data packets using mixing and splitting operation 1148, followed by re-scrambling the new data packets using scrambling operation 926, and forwarding these packets on to the meshed communication network. As shown in FIG. 78B, the sequence of performing multiple independent unscrambling operations 928 on each input followed by mixing operation 1089 together comprises unscrambled mixing of meshed inputs operation 1156A. For convenience sake, the sequence may be represented symbolically by unscramble and mix operation 1161.

(527) The inverse of the unscramble and mix operation, the split and scramble operation 1156B for meshed outputs, illustrated in FIG. 78C, comprises the sequence of splitting a data packet with splitting operation 1106 followed by performing multiple independent scrambling operations 926 for each output. For convenience sake, the sequence may be represented symbolically by split and scramble operation 1162. As shown in FIG. 78D, the sequential combination of the twocombining unscrambled mixing of meshed inputs operation 1156A followed by the split and scramble operation 1156B for meshed outputs comprises the re-scramble and remix operation for meshed transport shown symbolically as operation 1163.

(528) The application of the aforementioned unscrambled mixing of meshed inputs operation 1161 followed by the split and scramble operation 1162 for meshed outputs is shown in FIG. 79A, where fixed length data packet inputs 1157B, 1157D, 1157F, and 1157H from corresponding communication nodes N.sub.a,b, N.sub.a,d, N.sub.a,f and N.sub.a,h are processed by unscrambled mixing of meshed inputs operation 1156 in communication node N.sub.a,j to form long data packet 1160. While operation 1156 includes functionality for independently unscrambling the incoming data packets prior to mixing, the step is not required and therefore skipped because fixed-length data packet inputs 1157B, 1157D, 1157F, and 1157H are not scrambled. Long data packet 1160 is next processed by split and scramble operation 1162 resulting in mixed, scrambled data packets 1158N, 1158Q, 1158S and 1158V sent on to corresponding communication nodes N.sub.a,n, N.sub.a,q, N.sub.a,s and N.sub.a,v for meshed transport.

(529) The same scrambled mix and split operation for meshed transport of fixed-length packets is illustrated in FIG. 79B for incoming data packets 1165B, 1165D, 1165F, and 1165H that are scrambled. These data packets include junk data segments, as indicated by the data segments without an identifying number. Unscrambling and mixing operation 1161 in communication node N.sub.i,j then creates long packet 1166 that is shorter than the prior example because the junk data packets have been intentionally removed. In an alternative embodiment of the invention, the junk packets can be retained. Long packet 1166 is next processed by splitting and scrambling operation 1162 to produce multiple data packet outputs 1165N, 1165Q, 1165S and 1165V, sent on to corresponding communication nodes N.sub.a,n, N.sub.a,q, N.sub.a,s and N.sub.a,v for meshed transport. In these data packets, junk data has been reinserted to fill the data packets with a prescribed number of data segments. While in general it is preferred and easier to process inserting junk data segments at the end of a data packet, like that shown by data packets 1165N and 1165S, if the algorithm so prescribes, the junk packets could optionally be inserted elsewhere in a data packet, e.g. in the first slot as shown in data packet 1165V.

(530) An example of dynamic meshed data transport with static scrambling across communication network 1114 in accordance with this invention is illustrated in FIG. 80, which includes a network of interconnected computer servers 1118 running SDNP communication software. Communication node N.sub.0,0 performs scramble and split operation 1162, communication node N.sub.f,f performs mix and unscramble operation 1161, and all the other communication nodes perform re-scramble and remix operation 1163. Although in the example shown each server performs only one dedicated operation, it is understood that the SDNP software installed on all computer servers 1118 is capable of performing any of the SDNP functions as required including scramble and split operation 1162, unscramble and mix operation 1161, re-scramble and remix operation 1163, and others as disclosed herein

(531) In operation, incoming data packet 1055 is first scrambled by communication node N.sub.0,0 at time t.sub.1 by scramble and split operation 1162, creating scrambled data packet 1130, which is then split into four packets of varying length, specifically data packet 1170A comprising data segment 1F and associated a junk data segment in the first slot, packet 1170B comprising data segment 1C, data packet 1170C comprising data segments 1A and 1D in reverse order, and data packet 1170D comprising data segments 1B and 1E in ascending order. The data segments shown may be combined with other data segments from other data packets and conversations, also of variable length, where data segments from other conversations have been intentionally left out of the illustration for clarity's sake. It will be understood that time passes as the data packets traverse the network and their contents are split and remixed. For the purpose of illustration clarity, however, the times have been intentionally left out of the drawing except for some exemplary times shown at the beginning and conclusion of the communication process.

(532) During dynamic meshed transport the data packet's content, its data segments change as it traverses the network. For example, data packet 1170A, comprising a junk data segment and a data segment 1F, traverses communication nodes in sequence from communication node N.sub.0,0 first to communication node N.sub.1,1 then on to communication node N.sub.2,1, where it is mixed with data packet 1170B comprising data segment 1C, to form data packet 1171A, containing the data segment sequence 1C, 1F, and the junk data segment, which is sent to communication node N.sub.1,2, and then on to communication node N.sub.2,3. During the same time period, data packet 1170C comprising the data segment sequence 1D, 1A is transported from communication node N.sub.0,0 to communication node N.sub.3,1 where it is forwarded unchanged as data packet 1171C to communication node N.sub.3,2. As part of the mixing and splitting operation performed by communication node N.sub.3,1, a second data packet 1171B, comprising entirely junk data with no content, is generated and sent to communication node N.sub.2,1. The reason for routing an entirely junk packet devoid of content is two-foldfirst to confuse cyber-pirates by outputting more than one data packet from communication node N.sub.3,1, and second to gain updated intra-network propagation delay data from otherwise unused links or routes.

(533) Upon entering communication node N.sub.3,2 data packet 1171C is split into two data packets, data packet 1172C comprising data segment 1D, which is sent to communication node N.sub.3,3, and data packet 1172B comprising data segment 1A and a leading data segment comprising junk data, which is sent to communication node N.sub.2,3. Upon reaching server N.sub.2,3, data packet 1172B is mixed with incoming packet 1171A and then split again into packet 1173A, comprising data segments 1F and 1A, and sent to communication node N.sub.1,4 where trailing junk data segments are added to form data packet 1174A, which is sent on to final communication node N.sub.f,f at time t.sub.14. In a concurrent sequence, as a result of the splitting operation performed in communication node N.sub.2,3, data packet 1173B is sent onward to communication node N.sub.3,4 where a trailing junk data segment is added to data segment 1C before sending it on to final communication node N.sub.f,f at time t.sub.16 (time not shown).

(534) Meanwhile, data packet 1170D comprising data segments 1E and 1D is transported from communication node N.sub.0,0 to communication node N.sub.4,1 and on to communication node N.sub.4,2 where it is re-scrambled, forming data packet 1172D, comprising data segments 1B and 1E in reverse order. Upon entering communication node N.sub.2,3, data packet 1172D is mixed with data packet 1172C and then split anew, forming data packets 1173C and 1173D. Data packet 1173C, comprising data segment 1B is sent to communication node N.sub.2,4, where it is forwarded on to final server N.sub.f,f at time t.sub.15 as data packet 1174B. Although data packets 1173C and 1174B are identical, each containing only data segment 1B, i.e. packet 1173C is in effect unchanged by communication node N.sub.2,4, this is consistent with time t.sub.15 and its corresponding state, including seeds, keys, shared secrets, algorithms, etc., in communication node N.sub.2,4. The other data packet, i.e. data packet 1173D, exiting communication node N.sub.3,3 is then routed to communication node N.sub.4,3 and on to communication node N.sub.4,4, where an intervening junk data segment is inserted between data segments 1E and 1D to create data packet 1174D at time t.sub.17 with corresponding state 1137. Data packets 1174A, 1174B, 1174C, and 1174D, each formed using different states and created at different times, specifically at times t.sub.14, t.sub.15, t.sub.16, and t.sub.17 are then unscrambled and mixed together in communication node N.sub.f,f, using unscramble and mix operation 1161, to recreate the original unscrambled data packet 1055 at time t.sub.f. All nodes know what to do to process an incoming packet of data either because the state of the packet or another identifier corresponds to a set of shared secrets known by the node or because a separate server called a signaling server to the node a priori what to do when a particular packet arrives

(535) As in static meshed transport, in dynamic meshed transport the data paths may be of different lengths and exhibit different propagation delays. As a result, some data packets may arrive at final communication node N.sub.f,f before others. In such instances, in accordance with this invention, the data packets must be held temporarily in communication node N.sub.f,f until the other related data packets arrive. And while the drawing shows that the final assembly and recovery of original data packet 1055 occurs in communication node N.sub.f,f in practice the final packet reassembly can occur in a device such as a desktop, notebook, cell phone, tablet, set top box, automobile, refrigerator, or other hardware device connected to the network. In other words, in regards to meshed transport, there is no distinction between a communication node and a device connected to a communication node, i.e. communication node N.sub.f,f could be considered a desktop computer instead of being a true high-capacity server. The connection of a device to the disclosed SDNP cloud, i.e. the last-mile connection, is discussed in further detail later in this application.

(536) As stated previously, the aforementioned dynamic routing can be combined with one or more of the aforementioned SDNP methods as disclosed, including scrambling, encryption, or combinations thereof. One such operation, encrypted mixing and splitting operation 1180 shown in FIG. 81A performs a sequence of SDNP specific operations on multiple incoming data packets from communication nodes N.sub.a,b, N.sub.a,d, N.sub.a,f and N.sub.a,h comprising decryption operations 1032 performed on each incoming data packet, mixing and the splitting the data packets using mixing and splitting operation 1148, followed by re-encrypting the new data packets using encryption operation 1026, and forwarding these packets across the meshed communication network. As illustrated, incoming data packets have been previously encrypted and comprise illegible ciphertext packets 1181A, 1183A and others not shown. The decryption keys needed to decrypt the ciphertext inputs, specific to the time, state, and encryption algorithms used to create each incoming packet must be passed to decryption operation 1032 prior to performing decryption, either as a shared secret, keys present in a non-encrypted data packet sent with the specific data packet or communiqu?, or keys supplied through other communication channels. As described later in the disclosure, the keys may be symmetric or asymmetric. The topic of key exchange is discussed later in this disclosure.

(537) Once decrypted, the data packets become plaintext packets 1182A, 1184A and others not shown, then are mixed by communication node N.sub.a,j into long packet 1185, also comprising plain text, and subsequently split into new plaintext packets 1182B, 1184B and others not shown. Using new different encryption keys based on that specific time or state, the data packets are then encrypted to form new ciphertext packets 1181B, 1183B and others not shown, sent to other communication nodes. As shown in FIG. 81B, the sequence of performing multiple independent decryption operations 1032 on each input followed by mixing operation 1089 together comprises decrypting mixing of meshed inputs represented symbolically by decrypting mixing operation 1090. The splitting and encrypting operation for meshed outputs, illustrated in FIG. 81C, comprises the sequence of splitting a data packet with splitting operation 1106 followed by performing multiple independent encryption operations 1026 for each output. For convenience sake, the sequence may be represented symbolically by splitting and encrypting operation 1091.

(538) FIG. 82A illustrates an example of re-encrypting, re-scrambling and re-splitting data packets from multiple communication nodes N.sub.a,b, N.sub.a,d, N.sub.a,f and N.sub.a,h for meshed transport in accordance with this invention Using re-encryption re-scrambling mixing and splitting operation 1201 on incoming data packets entering communication node N.sub.a,j each incoming data packet is independently decrypted by a decryption operation 1032, unscrambled by an unscrambling operation 928, then mixed by mixing operation 1089, and subsequently split into multiple new data packets by splitting operation 1106. Each data packet is then independently scrambled again using scrambling operation 926, encrypted again using encryption 1026 and then forwarded onward using the meshed communication network. As illustrated, incoming data packets have been previously encrypted and comprise illegible ciphertext 1194A, 1197A and others not shown

(539) The time and state information, shared secrets, numeric seeds, algorithms, and decryption keys needed to unscramble and decrypt the ciphertext inputs, specific to the time, state, and algorithms used to create each incoming packet must be passed to decryption operation 1032 prior to performing decryption and to unscrambling operation 928, either as a shared secret, keys or numeric seeds present in an unencrypted data packet sent with the specific data packet or communiqu?, or keys and numeric seeds supplied through other communication channels. The keys may be symmetric or asymmetric. The topic of key exchange and numeric seed delivery is discussed later in this disclosure. All nodes know what to do to process an incoming packet of data either because the state of the packet or another identifier such as the seed corresponds to a set of shared secrets known by the node or because a separate server called a signaling server to the node a priori what to do when a particular packet arrives

(540) Once decrypted, the plaintext packets 1195A, 1198A and others not shown, are then unscrambled using unscrambling operations 928 to create corresponding unscrambled plaintext packets 1196A, 1199A and others not shown. Using mixing operation 1089, the unscrambled plaintext packets are mixed by communication node N.sub.a,j into long packet 1220, which is subsequently split into new unscrambled plaintext packets 1196B, 1199B and others not shown in splitting operation 1106, and then scrambled anew by scrambling operations 926 using new numeric seeds corresponding to the present time or state to form scrambled plaintext packets 1195B, 1198B and others not shown. Using new, different encryption keys based on that specific time or state, the data packets are next encrypted again by encryption operations 1026 to form new ciphertext 1194B, 1197B and others not shown, and subsequently sent to other communication nodes.

(541) As disclosed in accordance with this invention, SDNP communication can comprise any sequence of encryption, scrambling, mixing, splitting, unscrambling, and decryption. At least in theory, if the executed sequence occurs in a known sequence, described mathematically as the functions y=H{G[F(x)]} where innermost function F is performed first and outermost function H is performed last, then in order to recover the original data x the anti-function should performed in the inverse sequence where H.sup.?1 is performed first F.sup.?1 and is performed last, i.e. x=F.sup.?1{G.sup.?1[H.sup.?1(y)]}. This first-in last-out operation sequence should undo the alterations and recover the original content, but only if no data is removed from or inserted into the packets in the course of the process. If data is removed from or inserted into the packets, the scrambled or encrypted file is contaminated and cannot be repaired. For example, mixing data encrypted using different encryption methods yields data that cannot be unencrypted without first recovering the original components. One key benefit of dynamically meshed communication using SDNP transportobscuring all content by dynamically mixing, splitting and rerouting multiple conversations, is lost if a given communication node is not free to mix or split packets as needed.

(542) It is therefore one embodiment of SDNP communication to independently perform scrambling and encryption on the data packets exiting a communication node's individual outputs rather than to mix the data packets prior to the scrambling and encryption operations. Correspondingly, if the data packets entering a communication node are encrypted, scrambled, or both, then they should be independently unscrambled and unencrypted prior to mixing, i.e. prior to forming the long, mixed packet. As such the preferred operating sequence for incoming packets is to sequentially decrypt, unscramble and mix the incoming data on each input of a communication node, or in an alternative sequence to unscramble, decrypt, and mix the incoming data.

(543) The former case is illustrated in FIG. 82B where the decrypt, unscramble and mix meshed inputs operation, schematically shown as DUM operation 1209 and symbolically by DUM operation 1210, comprises independently performing for each input the sequence of decryption operation 1032, unscrambling operation 928, and then mixing the resulting data packets using mixing operation 1089. The individual switches 1208A and 1208B, present on each input are used to divert, as needed, data packets around one of decryption operations 1032 or one of unscrambling operations 928, respectively. For example if both switches in a specific input are open, then all data packets must pass through both the accompanying decryption operation 1032 and the accompanying unscrambling operation 928, and the data packet will necessarily be decrypted and unscrambled. When both-switches are closed, the operations are shorted out, and the data is not processed by either the decryption operation 1032 or the unscrambling operation 928, i.e. the data is passed into the mixing operation 1089 unchanged.

(544) If switch 1208A is closed and 1208B is open, then the data is diverted around decryption operation 1032 but passes through unscrambling operation 928 meaning the incoming data packet will be unscrambled but not decrypted. On the other hand, if switch 1208A is open and switch 1208B is closed, the data will pass through decryption operation 1032 but be diverted around unscrambling operation 928, meaning the incoming data packets will be decrypted but not unscrambled. Since the decryption operations 1032 and the unscrambling operations 928 are generally implemented in software, there are no physical switches diverting the signal. The switches 1208A and 1208B symbolically represent the operation of the software. Specifically, if a switch parallel to an operation is open, the applicable software performs the operation, and if the switch parallel to an operation is closed, the applicable software does not perform the operation but simply passes its input to its output unchanged. In the electronics metaphor, the function is shorted out by a closed switch so that the signal passes through unprocessed. The combinations are summarized in the following truth table where switch 1208A in parallel with decryption operation 1032 is referred to as switch A and switch 1208B in parallel with scrambling operation 928 is referred to as switch B.

(545) TABLE-US-00008 Effect of Switch A Switch B Decryption Unscrambling data Packet Open Open Yes Yes Decrypted then Unscrambled Closed Open No Yes Unscrambled Only Open Closed Yes No Decrypted Only Closed Closed No No Data Packet Unaltered

(546) The inverse function, the split, scramble and encryption operation is shown in FIG. 82C schematically by SSE operation 1209 and symbolically by SSE operation 1213, comprising splitting using split operation 1106 followed by independently performing unscrambling operation 926 followed by encryption operation 1026. Switches 1211B and A, present on each input are used to divert, as needed, data packets around either scrambling operation 926 or encryption operation 1026 respectively. For example, if both switches 1211B and 1211A in a specific input are open, then all data packets must pass into and be processed by scrambling operation 926 and encryption operation 1026, and the data packet will necessarily be scrambled and encrypted. When both switches are closed, the operations are shorted out and the data passes through the switches 1211B and 1211A and is not processed by either the scrambling operation 926 or the encryption operation 1026, meaning the data in that particular input is passed from the splitting operation 1106 to the output unchanged.

(547) If switch 1211B is closed and 1211A is open, then the data is diverted around scrambling operation 926 but processed by encryption operation 1026, meaning that the outgoing data packet will be encrypted but not scrambled. Alternatively, if switch 1211B is open and switch 1211A is closed, the data will be processed through scrambling operation 926 but be diverted around encryption operation 1026, meaning that the outgoing data packets will be scrambled but not encrypted.

(548) As stated previously, since the scrambling operations 926 and the encryption operations 1026 are generally implemented in software, there are no physical switches diverting the signal, and the switches 1211B and 1211A symbolically represent the operation of the software. Specifically, if a switch parallel to an operation is open, the applicable software performs the operation, and if the switch parallel to an operation is closed, the applicable software does not perform the operation but simply passes its input to its output unchanged. In the electronics metaphor, the function is shorted out by a closed switch so that the signal passes through unprocessed. The combinations are summarized in the following truth table where switch 1211B in parallel with scrambling operation 926 is referred to as switch B and switch 1211A in parallel with encryption operation 1026 is referred to as switch A.

(549) TABLE-US-00009 Effect of Switch B Switch A Scrambling Encryption data Packet Open Open Yes Yes Scrambled then Encrypted Closed Open No Yes Encrypted Only Open Closed Yes No Scrambled Only Closed Closed No No Data Packet Unaltered

(550) The combination of a multiple-input DUM 1209 and multiple-output SSE 1212 forms a highly versatile element for achieving secure communication in accordance with this invention, herein referred to as a SDNP media node 1201, shown in FIG. 83A. As shown the data entering any one of the multiple inputs may in sequence first be decrypted by decryption operation 1032, or decryption operation 1032 may be bypassed. The data packet may then be unscrambled by unscrambling operation 928, or unscrambling operation 928 may be bypassed. The various inputs once processed may be then be mixed using mixing operation 1089, and subsequently split into new packets by splitting operation 1106. Each individual output's data packets are next scrambled by scrambling operation 926, or alternatively scrambling operation 926 is bypassed, and then encrypted by encryption 1026 or alternatively encryption operation 926 may be bypassed.

(551) The name media node reflects the application of this communication node's communication software, or soft-switch in accordance with this invention, specifically to carry, route and process content representing real-time voice, text, music, video, files, code, etc., i.e. media content. The SDNP media node is also represented symbolically for convenience as SDNP media node M.sub.a,j, hosted on server 1215, as shown in FIG. 83B. Using the same code, all combinations of signal processing are possible using the disclosed SDNP media node, including the following examples: Single Route Pass-Through where a single input is routed to single output as is or alternatively by inserting or removing junk packets or parsing the incoming data packet into multiple shorter data packets. This function, shown in FIG. 83C schematically and symbolically as single route pass-through operation 1217A, is useful when a media node is operating simply as a signal repeater in a communication network. The junk and parse functions 1053 and 1052 as shown are integral features of packet mixing operation 1061 and packet splitting operation 1057 and are included here only for convenience sake. Redundant Route Replication where a single input is copied and sent as is to two or more outputs, or alternatively by inserting or removing junk packets or parsing the incoming data packet into multiple shorter data packets before forwarding identical copies and/or data sequences to two or more outputs. This function, shown schematically and symbolically in FIG. 83D as redundant route replication operation 1217B, is useful in implementing race routing for VIP clients or urgent communication, i.e. sending two copies by different paths and using the one that arrives at its destination first. The junk and parse functions 1053 and 1052 are integral features of packet mixing operation 1061 and packet splitting operation 1057 and are included here only for convenience sake. Single Route Scrambling where a single input is scrambled and routed to a single output irrespective as to whether the packet was previously encrypted. As shown in FIG. 83E, single-route scrambling is useful for first-mile communication between a client and the cloud or in communiqu?s before data packets are split or mixed for multi-route or meshed transport. The function represented schematically and symbolically as single route scrambling operation 1217C, comprises single input packet splitting operation 1057, in this case used only for junk insertions and deletions and for parsing, followed by scrambling-only operation 1268B. Single Route Unscrambling the inverse of single-route scrambling, shown symbolically as single route unscrambling operation 1217D in FIG. 83F, is used to return a scrambled packet to its unscrambled state irrespective as to whether the packet was previously encrypted prior to scrambling. The function comprises the series combination of unscrambling only operation 1226A followed by single-route mixing operation 1061 used for junk insertions and deletions and for packet parsing. By performing the two prior single-route unscrambling and scrambling functions in sequence, Single Route Re-scrambling, shown schematically and symbolically as single route re-scrambling operation 1216C in FIG. 83G, is useful to dynamically refresh packet scrambling in single path routes. Single Route Encryption where a single input is encrypted and routed to a single output irrespective as to whether the packet was previously scrambled. This function, represented schematically and symbolically as single route encryption operation 1217E in FIG. 83H, is useful for first-mile communication outside the cloud or for communiqu?s before data packets are split or mixed for multi-route or meshed transport. The function as shown comprises single-input packet splitting operation 1057, in this case used only for junk insertions and deletions and for parsing, followed by encryption-only operation 1226D. The inverse of single-route encryption, Single Route Decryption shown symbolically as single route decryption operation 1217F in FIG. 83I is used to return an encrypted packet to its unencrypted state irrespective as to whether the packet was previously scrambled prior to encryption. The function comprises the series combination of decryption only operation 1226C followed by single-route mixing operation 1061 used for junk insertions and deletions and for packet parsing. By performing the two prior single-route decryption and encryption functions in sequence, Single Route Re-encryption, shown schematically and symbolically as single route re-encryption operation 1216D in FIG. 83J, is useful to dynamically refresh packet encryption in single path routes Single Route Scrambling Encryption where a single input is both scrambled, encrypted, and routed to a single output. This function, represented schematically and symbolically as single route scrambling encryption operation 1217G in FIG. 83K is useful for first-mile communication outside the cloud or for communiqu?s before data packets are split or mixed for multi-route or meshed transport. The function as shown comprises single-input packet splitting operation 1057, in this case used only for junk insertions and deletions and for parsing, followed by scrambling and encryption operation 1226E. The inverse of single-route scrambling encryption, Single Route Unscrambling Decryption shown symbolically as single route unscrambling decryption operation 1217G in FIG. 83L, is used to return a scrambled encrypted packet to its original unscrambled unencrypted state. The function comprises the series combination of decryption unscrambling operation 1226D followed by single-route mixing operation 1061 used for junk insertions and deletions and for packet parsing. By performing the prior single-route decryption, unscrambling, scrambling and encryption functions in sequence, Single Route Re-packeting, shown schematically and symbolically as single route re-packeting operation 1216E in FIG. 83M, is useful to dynamically refresh packet scrambling and encryption in single path routes. Meshed SDNP Gateway Input also known as single-input, multiple-output SDNP gateway shown schematically and symbolically as single-input, multiple-output operation 1216F in FIG. 83N, where a single input is split and routed to multiple outputs for multi-route or meshed transport irrespective as to whether the packet was previously scrambled or encrypted. This function is useful to initiate unscrambled un-encrypted meshed routing in a SDNP gateway, including junk and parse functions 1053 and 1052 as an integral feature of its packet splitting operation. The inverse of the prior meshed gateway input function is Meshed Packet Gateway Output also known as multi-input, single-output SDNP gateway shown schematically and symbolically as multi-input, single-output operation 1216G in FIG. 83O, where a single input is split and routed to multiple outputs for multi-route or meshed transport irrespective as to whether the packet is scrambled or encrypted. The function is used to re-collect the component packets of a message in a SDNP gateway for last-mile communication or for cloud-to-cloud hops, i.e. to conclude SDNP meshed routing and optionally includes junk and parse functions 1053 and 1052 as an integral feature of packet its mixing operation. Scrambled SDNP Gateway Input is shown symbolically as single-input, multiple-output scrambling operation 1217H in FIG. 83P, where a single input is split, scrambled separately for each output, and then routed to multiple outputs for multi-route or meshed transport irrespective as to whether the packet was previously encrypted. This function is useful to initiate scrambled meshed routing in a SDNP gateway including optional junk and parse functions (not shown) as an integral feature of its splitting operation. The inverse of the prior scrambled gateway input function is Unscrambled SDNP Gateway Output also known as unscrambling multi-input, single-output SDNP gateway is shown symbolically as multi-input, single-output unscrambling operation 1217J in FIG. 83P where multiple meshed inputs are first independently unscrambled and then mixed and routed to a single output or client irrespective as to whether the packet is encrypted. The function is used to re-collect and unscramble the component packets of a message in a SDNP gateway for last-mile communication or for cloud-to-cloud hops, i.e. to conclude SDNP meshed routing and optionally includes junk and parse functions (not shown) as an integral feature of its packet splitting operation. Encrypted SDNP Gateway Input is shown symbolically as single-input, multiple-output encryption operation 1217K in FIG. 83Q, where a single input is split, encrypted independently for each output, and then routed to multiple outputs for multi-route or meshed transport irrespective as to whether the packet was previously scrambled. This function is useful to initiate encrypted meshed routing in a SDNP gateway including optional junk and parse functions (not shown) as an integral feature of its splitting operation. The inverse of the prior encrypted gateway input function is Decrypted SDNP Gateway Output, shown symbolically as multi-input, single-output decryption operation 1217L in FIG. 83Q, where multiple meshed input are first decrypted independently for each input then mixed and routed to a single output or client irrespective as to whether the packet is scrambled. The function is used to re-collect and decrypt the component packets of a message in a SDNP gateway for last-mile communication or for cloud-to-cloud hops, i.e. to conclude SDNP meshed routing including optional junk and parse functions (not shown) as an integral feature of its packet mixing operation Scrambled Encrypted SDNP Gateway Input is shown symbolically as single-input, multi-output scrambling-encryption operation 1217M in FIG. 83R, where a single input is split, then scrambled and subsequently encrypted independently for each output, and finally routed to multiple outputs for multi-route or meshed transport. This function is useful to initiate encrypted meshed routing in a SDNP gateway including optional junk and parse functions (not shown) as an integral feature of its splitting operation. The inverse of the prior scrambled encrypted gateway input function is Unscrambled Decrypted SDNP Gateway Output is shown symbolically as multi-input, single-output unscrambling-decryption operation 1217N in FIG. 83R, where multiple meshed inputs are first decrypted then unscrambled independently for each input, then mixed and routed to a single output or client. The function is used to re-collect, decrypt and unscramble the component packets of a message in a SDNP gateway for last-mile communication or for cloud-to-cloud hops, i.e. to conclude SDNP meshed routing including optional junk and parse functions (not shown) as an integral feature of its packet mixing operation. Meshed Re-scrambling is shown symbolically as multi-input, multi-output unscrambling-scrambling operation 1216A in FIG. 83S where multi-route or meshed inputs are first unscrambled independently for each input irrespective as to whether the packet is encrypted, merged into a long data packet or equivalent, removing junk packets if applicable. The long data packet is next split into multiple new data packets, inserting junk data as applicable. Each data packet is then independently scrambled and finally routed to multiple outputs for multi-route or meshed transport. The function is used to refresh scrambling to new state or time conditions, i.e. to facilitate data packet re-scrambling, as data packets traverse the SDNP cloud. Meshed Re-encryption is shown symbolically as multi-input, multi-output decryption-encryption operation 1216B in FIG. 83S, where multi-route or meshed inputs are first decrypted independently for each input irrespective as to whether the packet is scrambled, merged into a long data packet or equivalent, removing junk packets if applicable. The long data packet is next split into multiple new data packets inserting junk data as applicable. Each data packet is then independently encrypted and finally routed to multiple outputs for multi-route or meshed transport. The function is used to refresh encryption to new state or time conditions, i.e. to facilitate data packet re-encryption, as data packets traverse the SDNP cloud. Meshed Re-packeting shown previously in schematic form in FIG. 83A and in symbolic form in FIG. 83B where a where multi-route or meshed inputs are first decrypted and subsequently unscrambled independently for each input, and next merged into a long data packet or equivalent, removing junk packets if applicable. In one embodiment, the long packet should comprise unencrypted plaintext or the format of data sent from a client. Thereafter, the long data packet is split into multiple new data packets inserting junk data as applicable. Each data packet is then independently scrambled and encrypted and finally routed to multiple outputs for multi-route or meshed transport. The function is used to refresh both scrambling and encryption to new state or time conditions, i.e. to facilitate data packet re-packeting, as data packets traverse the SDNP cloud.

(552) The above preferences are not intended to limit the possible permutations and combinations by which the disclosed SDNP media node can be used. For example, the number of input and output channels, i.e. the number of SDNP media nodes connected to any specific SDNP media node may vary from one to dozens of connections per device. Four inputs and outputs are shown for convenience. FIG. 84A, a schematic diagram representing signal flow, illustrates the communication between any nodes such as media nodes M.sub.a,b, M.sub.a,j and M.sub.a,h comprising computer servers 1220B, 1220J, and 1220H respectively all running the SDNP communication software. This drawing illustrates two connections between any two media nodesone connected from an output of a media node, e.g. M.sub.a,b, to an input of another media node, e.g. M.sub.a,j and a second connection from an output of the last named media node, M.sub.a,j to an input of the former media node, M.sub.a,b. This depiction is meant to represent a layer 3 network connection, not a PHY or data link layer which may in fact comprise a single fiber, coaxial link, twisted pair, Ethernet, or satellite link between the communication media nodes. Because the representation is at a network level, there is no risk of electrical feedback, race conditions, or instability created by having the output of a device connected to another device's input and that device's output connected to the former device's input, i.e. the network schematic does not describe an electrical feedback network.

(553) In order to realize a communication network or SDNP cloud 1114 in accordance with this invention, as shown in FIG. 84B, an array of computer servers comprising servers 1220B, 1220D, 1220F, 1220H, 1220J, 1220S, and 1220Q, each running software to implement an SDNP media node 1215, create a secure network with corresponding media nodes M.sub.a,b, M.sub.a,d, M.sub.a,f, M.sub.a,h, M.sub.a,j, M.sub.a,s, and M.sub.a,q, which may represent a portion of the nodes of a larger secure cloud.

(554) The computer servers need not necessarily run the same operating system (OS) so long as the software running in SDNP media node 1215 comprises executable code consistent with the hardware's OS. Executable code is the computer software running on a given hardware platform performing specific application functions. Executable code is created by compiling source code. While source code is recognizable as logically organized sequential operations, algorithms, and commands, once the source code is converted into executable code, the actual functionality of the program is difficult or impossible to recognize. The process is unidirectionalsource code can generate executable code but executable code cannot be used to determine the source code from whence it came. This is important to prevent theft of the operating system so hackers can reverse engineer the actual code.

(555) Source code is not executable because it is a language and syntax used by programmers, not machine code intended to be executed on a specific operating system. During the compile operation, the executable code generated is specific to one operating system, iOS, Android, Windows 9, Windows 10, MacOS, etc. Executable code for one operating system will not run on another. Source code can, however, be used to generate executable code. The source code of the SDNP network is therefore available only to the developers of its source code and not to the network operators running SDNP executable code.

(556) Network connectivity, typically following standardized protocols such as Ethernet, WiFi, 4G, and DOCSIS described in the background section of this application provide a common framework to interconnect the devices in a manner completely unrelated to their manufacturer or OS. In operation, the network connection delivers and transmits data packets to and from the computer server's operating system which routes it to and from the SDNP software running atop the computer's OS. In this manner, the SDNP media node based soft-switch communication function can be realized in any device, regardless of its manufacturer, and can be made compatible with any major supported operation system including UNIX, LINUX, MacOS 10, Windows 7, Windows 8, etc.

(557) Another principle is that the SDNP-realized cloud has no central control point, no single device deciding the routing of packages, and no common point that has full knowledge of the data packets being sent, what they are, where they are going, and how they were mixed, split, scrambled, and encrypted. Even a network operator has no full picture of the data traffic in the network. As described, FIG. 84B represents a network of computers in the same cloud. The meaning of being in the same cloud is a subjective and arbitrary term and should not be meant to limit the universality of the disclosed invention. A second cloud comprising media nodes M.sub.b,b, M.sub.b,c, M.sub.b,f, M.sub.b,g, M.sub.b,j, M.sub.b,x, and M.sub.b,t (not shown) may comprise a different geographic region, or be hosted by a different service provider. For example, Amazon may host Cloud A, while Microsoft may host Cloud B, and a private company or ISP may host Cloud C. In general, the intra-nodal connectivity is greater and denser within a cloud than for cloud-to-cloud connections, which are fewer in number and require using true Internet compatible IP addresses to communicate rather than utilizing temporary packet routing numbers assigned by a network address translator (NAT).

(558) In regards to representing the functions performed by any given SDNP, the same principle of either including or bypassing a function with virtual switcheseither performing the function or passing the data through unaltered, is equally applicable to the above discussion or in an alternate embodiment where the scrambling and encryption functions are swapped in order, i.e. performing unscrambling before decryption, and performing encryption before scrambling. For brevity's sake, these alternate data flows are not illustrated separately with the understanding that the sequence may be altered so long that the inverse function is performed in the opposite operational sequence. Because the data packet processing occurs in software, this sequence can be altered simply by changing the algorithm's sequence on an ad hoc or periodic basis, e.g. monthly, daily, hourly, or on a call-by-call, time, or state basis.

(559) As discussed previously, any scrambling, encrypting and mixing sequence may be utilized so long that the original data is recovered in precisely the inverse order on precisely the same data set. Changing the content in between operations without undoing the change before unscrambling, decrypting, or remixing will result in irrevocable data loss and permanent data corruption. That said, a packet can even be scrambled more than once or encrypted more than once in a nested order so long the inverse sequence rule is followed to recover the original data. For example, the client application can encrypt a message using its own proprietary method to create ciphertext whereon upon entering the SDNP gateway, the gateway media node can encrypt the packet a second time for network transport. This method will work so long that the final gateway decrypts the network's encryption on a complete packet-by-packet basis, before the client application decryption occurs.

(560) Aside from the case of client-based encryption, to avoid the risk of data corruption and packet loss, in one embodiment in accordance with this invention, the following guidelines are beneficial in implementing SDNP based communication: SDNP packet scrambling should be performed in the client's SDNP-enabled application or alternatively upon entering a SDNP cloud in the SDNP media node gateway, Ideally, SDNP encryption should occur on every hop between two SDNP media nodes, i.e. a data packet is encrypted before routing and decrypted immediately upon entering the next SDNP media node. In the very least, re-scrambling should occur every time a data packet enters or leaves a SDNP cloud, either for last-mile communications or for cloud-to-cloud hops. If the data packet is SDNP encrypted, it should be decrypted before it is unscrambled, and then scrambled again before it is encrypted again. It is preferable to decrypt and unscramble incoming data packets before mixing. Decrypting and unscrambling mixed long packets can result in data corruption. Likewise it is preferable to scramble and encrypt data after splitting. Decrypting and scrambling mixed long packets can result in data corruption. Junk packets should be removed from incoming data packets after decryption and unscrambling but before mixing. Junk deletions on mixed long packets can result in data corruption. Likewise it is preferable to insert junk data after splitting but prior to scrambling and encryption. Junk insertions on mixed long packets can result in data corruption. User application encryption aside, re-scrambling (i.e. unscrambling and then scrambling) preferably should not be performed on encrypted data. Junk data insertions should be performed in a consistent manner for ease of insertion and removal. Incoming data packets should be decrypted and unscrambled in accordance with the time, state, and algorithms in which their encryption and scrambling occurred. Outgoing data packets should be encrypted and scrambled in accordance with the current time, associated state, and related algorithm. The plaintext packets are preferably recreated only within the media nodes. All packets are scrambled, encrypted, mixed, split and/or contain junk data segments while they are in transit between the media nodes.

(561) While the above methods represent possible methods in accordance with this invention, they are not intended to limit the possible combination or sequence of SDNP functions. For example, encrypted packages can be subsequently scrambled so long the same data packet is unscrambled before decryption.

(562) In one implementation, scrambling is only performed within a client's SDNP application and not by the media nodes in the SDNP cloud. In such cases, secure intra-node communication is purely a sequence of encryptions and decryptions like that shown in FIG. 84C, where the SDNP functional components of media node M.sub.a,h comprising splitting operation 1106, encryption operations 1225A, mixing operation 1089, and decryption operations 1225B is shown explicitly, while SDNP media nodes M.sub.a,f and M.sub.a,j are depicted performing SDNP media node function meshed re-encryption 1216B only symbolically.

(563) In operation, data coming into media node M.sub.a,j from another media node (not shown) is first directed to a decryption operation 1225B at one of the inputs of media node M.sub.a,h and into mixing operation 1089, where, if they arrive at the same time, the packets are combined with data packets coming from media node M.sub.a,f independently that have been processed by another decryption operation 1225B. Once mixed, the data packets are split into new and different combinations with different destinations based on a splitting algorithm executed by splitting operation 1106. The individual outputs are then independently encrypted by separate encryption operations 1225A, and then directed to media nodes M.sub.a,f and M.sub.a,j and on to other media nodes in the network.

(564) During this routing, the long packet momentarily existing between mixing operation 1089 and splitting operation 1106 may in fact contain data packets from the same conversation, one data packet traveling from media node M.sub.a,f to media node M.sub.a,j through media node M.sub.a,h, the other data packet traveling from media node M.sub.a,j through media node M.sub.a,h to media node M.sub.a,f at the same time but in the other direction. Because of precise routing control available in the SDNP network in accordance with this invention, described in greater detail later in this disclosure, a long data packet can, at any given time, contain any combination of related and unrelated content, even data or sound snippets from the same full duplex conversation going in opposite directions. If the data does not arrive at the same time, then the data packets pass serially through the media node in opposite directions without ever sharing the same long packet. In either case, there is no interaction or performance degradation in a SDNP media node carrying multiple conversations in full duplex mode.

(565) While at first this unique form of network communication may appear confusing, representing the data transport in a manner shown in FIG. 84D quickly reveals the simplicity of data communication in a SDNP media node, even when a media node supports both directions of full duplex communication concurrently. For example, data packets, shown as shaded lines, entering media node M.sub.a,h first pass through decryption 1032 then mixing operation 1089, splitting operation 1106 and encryption operation 1026 finally exiting media node M.sub.a,j and entering media node M.sub.a,h in a newly encrypted state, and thereafter repeating the same sequence but at a new time and state. Finally, the data packets from media node M.sub.a,h enter media node M.sub.a,f where they are decrypted, mixed, split and re-encrypted and finally sent to the next media node in the cloud. Concurrently, data passing the other direction, shown by un-shaded lines, enters media node M.sub.a,f where it is decrypted, mixed, split and re-encrypted then passed to media node M.sub.a,h and finally sent through media node M.sub.a,j to other media nodes in the SDNP cloud.

(566) Last-Mile Communication

(567) The data link between a client and the SDNP cloud is described herein as the last mile communication. The term last mile includes the first mile, the connection between a caller and the cloud, because all communication is invariably two-way involving a sent message and a reply, or possibly a full duplex conversation. As such, the term last mile, as used herein, shall mean any connection between a client and the SDNP cloud regardless as to whether the client initiated the call or was the person being called, i.e. the recipient. An example of a last-mile connection is illustrated in FIG. 85A, where SDNP cloud 1114 comprises a network of computer servers 1118 running software to operate as SDNP media nodes M.sub.a,b, M.sub.a,d, M.sub.a,f, M.sub.a,h, M.sub.a,j, M.sub.a,s, and M.sub.a,q, together representing at least a portion of the nodes of a secure cloud. Specifically, in the example shown, computer server 1220H, facilitating SDNP media node M.sub.a,h, operates as a SDNP gateway media node connected directly or indirectly to LTE base station 17 and is connected via cellular tower 18 and radio link 13 to cell phone as a client. As used herein, the term gateway node or gateway media node refers to a media node that connects with a node that is outside the SDNP network, typically a client device such as a cell phone or a computer, in which case, the connection between the gateway node and the client device is a last mile connection.

(568) An example where a secure SDNP gateway node connects to an unsecure last mile is shown in FIG. 85B, e.g. the SDNP gateway node is connected to a phone that does not have a SDNP application installed on it. As shown, cell phone 32 is connected by radio link 28 to cellular tower 18, which sends and receives data packets from cell phone 32 and converts them to wireline communications such as Ethernet, fiber, coaxial cable, copper cable, etc. using LTE base station 17. Although the data packets are carried bidirectionally on a single PHY layer 1 connection, wire, cable, radio or satellite link, the data flow is represented separately for packets sent from cell phone 32 to SDNP media node M.sub.a,h, and vice versa. As illustrated, the last mile is unsecure unless the application being used in the cell phone has built-in encryption and the person being called is using the same application with the same encryption.

(569) In operation, open data packets sent from cell phone 32 to SDNP gateway media node M.sub.a,h, are neither decrypted nor unscrambled because these functions are disabled, i.e. shorted out and as such are not shown. Instead incoming data packets are passed directly into mixer operation 1089 mixing them with other packets then splitting them out into multiple outputs for meshed transport using splitting operation 1106. Each of these outputs is then secured using scrambling operation 926 and encryption operation 1026 before transport. One output shown as an example is routed to media node M.sub.a,f, in server 1220F. The message may in turn be processed media node M.sub.a,f for intra-cloud communication as described previously and sent onward to another media node, e.g. media node M.sub.a,j in computer server 1220J.

(570) Data flow from the cloud to cell phone 32 from media node M.sub.a,f, in server 1220F and from other media nodes are processed in inverse sequence, starting with decryption operations 1032, and unscrambled using unscrambling operations 928, and then mixed with other incoming packets into a temporary long packet by mixing operation 1089. The long packet is then split into pieces by splitting operation 1106 directing some packets onward in the network and separating the packets to be sent to cell phone 32. These packets may be sent together or parsed and sent successively in separate data packets back to LTE base station 17 and onward to cell phone 32.

(571) The data packets traversing the network may be repeatedly re-encrypted and re-scrambled, as described previously. Alternatively, in one embodiment, the data packets remain scrambled without re-scrambling throughout the cloud but can be repeatedly re-encrypted at each media node. In such a scramble-once unscramble-once system, the scrambling occurs in the gateway node where the packets enter the cloud and the unscrambling occurs in the gateway node where the packets leave the cloud, i.e. in the gateway media nodes connected to the first and last miles. While, as noted above, a media node connected to the first or last mile may be called a gateway node, in actuality it comprises the same SDNP media node software and functionality as any other media node in the cloud, but functions differently in order to contact a client.

(572) Another option to implement scramble-once unscramble-once SDNP communication is to implement the scrambling in the client's device using software. As shown in FIG. 85C, in a connection between cell phone 32 and SDNP media node M.sub.a,h in computer server 1220F, SDNP media node M.sub.a,h acts as a gateway media node between the client and the SDNP cloud where SDNP gateway media node M.sub.a,h comprises mixing operation 1089, splitting operation 1106, encryption operation 1225A, scrambling operation 1226B, decryption operation 1225B and unscrambling operation 1226A. As defined previously, any media node, a communication node designated with an M node name, is capable of any combination of all these security operations, i.e. mixing and splitting, encrypting and decrypting, scrambling and unscrambling, etc. In operation, the data packets are scrambled within the cell phone 32 by SDNP software, travel by radio link 28 to LTE tower 18, where LTE base station 17 converts the signals into Ethernet, fiber, or other wireline for communication to the SDNP gateway node. Depending on the local carrier, portions of this link may comprise traffic over a private NAT or involve data traveling over the Internet. The data packets are then sent from LTE base station 17 to SDNP media node M.sub.a,h acting as a SDNP gateway node.

(573) The incoming data packet is then is routed to pass-through operation 1216H and subsequently mixed with other incoming data packets using mixing operation 1089, then split by splitting operation 1106, with the data packets from cell phone 32 directed to media node Mat through encryption operation 1225A. In this manner the data traversing the cloud is encrypted by the gateway but scrambled by the client's SDNP application. Conversely, encrypted and scrambled data traffic from the SDNP cloud is routed through media node M.sub.a,f, passed through decryption operation 1225B, mixed by mixing operation 1089, and split into new packets by splitting operation 1106, extracting the data packets with cell phone 32 as their destination, and sending the data packets to cell phone 32 unmodified by pass-through operation 1216H. In this manner, the entire communication is scrambled from end-to-end but only encrypted within the SDNP cloud.

(574) A modification to the above method still provides scrambling both in the last mile and in the cloud, but the last-mile scrambling is different than the scrambling used in the cloud. As shown in FIG. 85D, in a connection between cell phone 32 and SDNP media node M.sub.a,f in computer server 1220F, SDNP media node M.sub.a,h acts as a gateway node between the client and the SDNP cloud, where SDNP media node M.sub.a,h comprises mixing operation 1089, splitting operation 1106, scrambling and encryption operation 1226C, decryption and unscrambling operation 1226D, scrambling operation 1226B and unscrambling operation 1226A. In operation, data packets are scrambled within the cell phone 32 by SDNP software, travel by radio link 28 to LTE tower 18, and LTE base station 17 converts the signals into Ethernet, fiber, or other wireline communication to the SDNP gateway node. Depending on the local carrier, portions of the link from cell phone 32 to LTE base station 17 may comprise traffic over a private NAT or involve data traveling over the Internet. The data packets are then sent from LTE base station 17 to SDNP media node M.sub.a,h acting as a SDNP gateway node.

(575) The incoming data packet is then is routed to unscrambling operation 1226A and subsequently mixed with other incoming data packets using mixing operation 1089, then split by splitting operation 1106, with the data packets from cell phone 32 directed to media node M.sub.a,f through scrambling and encryption operation 1226C. In this manner, the data traversing the cloud is encrypted and scrambled by the gateway node but in a manner different than the scrambling used by the client's SDNP application for last-mile security. Conversely, encrypted and scrambled data traffic from the SDNP cloud is routed through media node M.sub.a,f, through decryption and unscrambling operation 1226D, then mixed by mixing operation 1089, and split into new packets by splitting operation 1106, extracting the data packets with cell phone 32 as their destination, and sending the data packets to cell phone 32 through scrambling operation 1226B. The data packets entering cell phone 32 are unscrambled by an SDNP-enabled application. In this manner, communication in the cloud is both encrypted and scrambled within the media nodes while the last mile is scrambled by the gateway node and the phone application in a manner distinct from the cloud scrambling. One important aspect of scrambling and un-scrambling data packets within the phone is the method used to pass state information, numeric keys, or shared secrets between the cloud and the client. This subject is discussed later in this disclosure.

(576) Fragmented Data Transport

(577) In accordance with this invention, a network of computer servers running software to perform SDNP media node functions facilitates secure global communication to a wide variety of devices based on data fragmentation in packet-switched communication. As illustrated in FIG. 86, SDNP cloud 1114, comprising a network of computer servers running software to operate as SDNP media nodes M.sub.a,b, M.sub.a,d, M.sub.a,f, M.sub.a,h, M.sub.a,j, M.sub.a,s, and M.sub.a,q and others not shown may connect to a large variety of devices and clients including: (a) LTE base station 17 with radio links 28 to cell phone 32 and tablet 33. Base station 17 may also be linked by radio to any other LTE-enabled device; (b) public WiFi system 100 with WiFi antenna 26 providing WiFi radio link 29 to notebook 35 or to tablets, cell phones, e-readers and other WiFi-connected devices, including Internet appliances; (c) cable CMTS 101 connected by optical fiber or coaxial cable to cable modem 103 and then to desktop computer 36 or home WiFi base station, Ethernet-connected devices, etc.; (d) cable CMTS 101 connected by optical fiber or coaxial cable to set top box TV STB 102 and then to HDTV 39; (e) a wireline connection to Internet routers 66A, 66B, 66C; (f) professional radio networks 14 such as TETRA and EDACs connected by radio tower 15 to walkie-talkie 16B, base stations 16A, and professional vehicles 40; (g) corporate broadcast exchange PBX 8 and desktop phones 9; and (h) PSTN bridge 3 to conventional phone networks and POTS. As shown, any SDNP media node can operate as a gateway node.

(578) A simplified illustration of data packet transport is illustrated in FIG. 87, showing examples of SDNP cloud-based communication between tablet 33 and automobile 1255, comprising data packet 1056, sequentially 2A, 2B, 2C, 2D, 2E and 2F, and between notebook 35 and cell phone 32, comprising data packet 1055, sequentially 1A, 1B, 1C, 1D, 1E, and 1F. Another data packet 1250, sequentially as 3A, 3B, 3C, 3D, 3E, and 3F; a data packet 1252, sequentially as 4A, 4B, 4C, 4D, 4E, and 4F; and a data packet 1251, sequentially as 5A, 5B, 5C, 5D, 5E, and 5F, are also transported through the network concurrent with data packets 1255 and 1256. The shorter packets represent components at various times during transport, displayed collectively to illustrate the dynamic nature of network transport.

(579) In the example shown, data of every packet is scrambled so the sequence of data segments may be in random order or may by chance be in ascending order. Data segments of one communiqu? or conversation may also be interspersed with unrelated data segments. In fact it is highly unlikely that a data packet once entering the SDNP cloud would not be mixed with other unrelated data segments. In fact in any given data packet transiting between two SDNP media node, the mixing of unrelated data segments and scrambling of the order of these packets is a normal condition. With a large number or conversation and data packets traversing the cloud simultaneously, the chance of all of the data remaining in the same data packet is statistically remote. In the absence of sufficient data, the mixing operation within the media nodes introduces junk data. The inclusion of various data segments of unrelated data as shown illustrates the principle of mixing of communiqu?s and conversations in data packets during SDNP transport, but does not accurately represent the true quantity and frequency of unrelated data or junk data segments and filler present in the data packets.

(580) FIG. 88A illustrates the beginning of communication at time t.sub.0 and corresponding state 990 from notebook 35 to cell phone 32 starting with data packet 1055 and unrelated data packets 1056 and 1250 through 1252 entering the network through various gateway nodes including M.sub.a,q, M.sub.a,h, M.sub.a,b, and M.sub.a,s. As shown in FIG. 88B, at time t.sub.1 and corresponding state 991, data packet 1055 is split into several component data packets. One such data packet 1261A comprising data segments 1A and 1B in ascending order but mixed with unrelated data segments, is sent to media node M.sub.a,b. Data packet 1261B comprising data segments 1D, 1C, and 1F in scrambled order and also mixed with unrelated data segments, is routed to media node M.sub.a,j, and packet 1261C comprising data segment 1E is sent to media node M.sub.a,b.

(581) As shown in FIG. 88C, at time t.sub.2 and corresponding state 992, the data is separated into new combinations of component data packets. Specifically, data packet 1261A is split into new data packets 1262A and 1262B where data packet 1262A comprising data segment 1A and other data segments is routed to media node M.sub.a,s, while data packet 1262B comprising data segment 1B is routed to media node M.sub.a,d. Data packet 1261B is also split into component data packets 1262C and 1262D, where data packet 1262C, comprising data segments 1C and 1F in ascending order but intermixed with unrelated data segments, is routed to media node M.sub.a,d while component data packet 1262D, comprising data segment 1D is directed to media node M.sub.a,f. Meanwhile, data packet 1262E comprising data segment 1E continues transit alone or mixed with unrelated data packets (not shown) to media node M.sub.a,f.

(582) As shown in FIG. 88D, at time t.sub.3 and corresponding state 993, data packet 1263A, comprising data segment 1A, and data packet 1263C comprising data segments 1D and 1E, are transported to media node M.sub.a,d while data packet 1263B, comprising data segments 1B, 1C and 1F, waits for their arrival in the same media node M.sub.a,d. As shown in FIG. 88E, at time t.sub.4 and corresponding state 994, media node M.sub.a,d mixes data packets 1263A, 1263B and 1263C, restoring the original data packet 1055, and routes the data packet 1055 to cell phone 32, either together or in piecemeal fashion. A summary of the data packet transport between notebook 35 and cell phone 32 is shown in FIG. 88F.

(583) As shown in FIG. 89A, independently of and concurrent with the communication between notebook 35 and cell phone 32, tablet 33 is communicating to automobile 1255, starting at time t.sub.0 and corresponding state 990, when data packet 1056 enters secure cloud 1114. As shown in FIG. 89B, at time t.sub.1 and corresponding state 991, the incoming data packet 1056 is split into component data packets 1261D and 1261E, where packet 1261D, comprising data segments 2B and 2C in scrambled but coincidentally ascending order, is routed to media node M.sub.a,q, and packet 1261E comprising data segments 2E, 2F, 2A and 2D in scrambled order, is routed to media node M.sub.a,j.

(584) As shown in FIG. 89C, at time t.sub.2 and corresponding state 992 data packet 1261D is modified, scrambling the data order and inserting data segments from other sources to create data packet 1262F. Likewise, data packet 1261E is split by media node M.sub.i,j into several data packets 1262G, 1262H, and 1262J. Data packet 1262J, comprising data segment 2A, is routed to media node M.sub.a,f. Scrambled data packet 1262H, comprising data segments 2D and 2E mixed with a number of unrelated data segments, is routed to media node M.sub.a,d. Also, at time t.sub.2 data packet 1262G comprising data segment 2F is routed to media node M.sub.a,s.

(585) As shown in FIG. 89D, at time t.sub.3, and corresponding state 993, data packet 1263D comprising data segments 2B and 2C in ascending order is routed to node M.sub.a,s where data packet 1263E, comprising data segment 2F, is waiting for other packets to arrive. Concurrently, data packet 1263G is routed to media node M.sub.a,d, where data packet 1263F, comprising data segments 2D and 2E in ascending order, is waiting. This condition highlights that in the SDNP network, data packets may transit immediately or, if desired, may be held temporarily. As shown in FIG. 89E, at time t.sub.4 and corresponding state 994, data packet 1264B comprising data segments 2D, 2A, and 2E in scrambled order, is routed to media node M.sub.a,s, where data packet 1264A, comprising data segments 2B, 2C, and 2F, is waiting. As shown in FIG. 89F, at time t.sub.f the final data packet 1056 is assembled and routed to automobile 1255, or alternatively all the data segment components of final data packet 1056 are routed in unmixed form to automobile 1255 and reassembled there. A summary of the routing of data packet 1056 from tablet 33 to automobile 1255 is shown in FIG. 89G.

(586) As shown, data packets transiting through the SDNP cloud carry multiple concurrent conversations to different destinations, dynamically changing in content from one SDNP media node to the next. There is no adverse impact, data loss, or bleeding from one conversation with another through the mixing or splitting of unrelated data segments. For example, as illustrated in FIG. 87, data packet 1257 contains data segments 1C and 1F routed to cell phone 32, data segments 2D and 2E routed to automobile 1255, and other unrelated data segments and junk data, all of which are delivered to different destinations unaffected by the temporary sharing of data packets with other un-related data segments.

(587) Moreover, since no data packet contains a complete word, sound, or conversation, the data fragmentation and meshed routing employed by the SDNP media nodes in accordance with this invention renders the data packet's content incomprehensible and invulnerable to man-in the middle attacks. As shown in FIG. 90, at time t.sub.1, man-in-middle attacker 630 sniffing data packets in transit in and out of media node M.sub.a,j sees only ciphertext packets 1270A, 1271A, 1272A, and 1273A. In the unlikely event that the encrypted files are broken, the underlying plaintext content of the packets 1270B, 1271B, 1272B, and 1273B comprises a scrambled incomplete mix of data segments. This data condition persists for only a fraction of a second before new data packets traverse the same media node. Even without scrambling and mixing, the limited time available to decrypt a data packet before it is re-encrypted, re-scrambled, re-split, or re-packeted renders even supercomputer attacks ineffective.

(588) FIG. 91A illustrates the dynamic nature of SDNP media transport using time as the basis by which to represent the data transport. The data shown here is the same as the data overlay illustrated in the network graph of FIG. 87. In a time based representation, data packet 1056 from tablet 33 is split into data packets 1261A, 1261B, and 1261C. At time t.sub.2, packet 1261A is split into new data packets 1262A and 1262B, and data packet 1261B is split into new data packets 1262C and 1262D; and data packet 1261C is updated to data packet 1262E without a change in content. At time t.sub.3, data packet 1262A is updated into data packet 1263A without changing its content; and data packets 1262B and 1262C are mixed into data packet 1263B, while data packets 1262D and 1262E are mixed into data packet 1263. At time t.sub.4, data packets 1263A, 1263B and 1263C are mixed to reconstitute data packet 1055.

(589) SDNP data transport can also be represented in tabular form. For example, table 1279, shown in FIG. 91B, illustrates the processing of data packets at time t.sub.3, showing the source media nodes, the incoming packets, the time the incoming packets were encrypted, the time the incoming packets were scrambled, the last time the data packets were mixed and split, i.e. meshed, and the resulting outbound packets. A media node uses this information in order to know what to do with incoming data packets, how to re-packet the data and how to re-encrypt or re-scramble the data if so desired.

(590) As shown in FIG. 91C, another aspect of dynamic nature of SDNP media transport is its ability to temporarily hold packets in a media node waiting for other packets to arrive. Using the same data as shown previously in FIG. 87, this mechanism is illustrated in a time-based representation of packet 1056. At time t.sub.1, the incoming data packet 1056 is scrambled and then split into data packet 1261D, comprising data segments 2B and 2C, and data packet 1261E, comprising packets 2A, 2D, 2E and 2F. At time t.sub.2, the communiqu? is broken into four pieces, data packets 1262F, 1262G, 1262H, and 1262J, the latter three the result of splitting data packet 1261E into data packet 1262G, comprising data segment 2F; data packet 1262H, comprising data segments 2D and 2E; and data packet 1262J comprising data segment 2A. Data packet 1261D, comprising data segments 2B and 2C, moves through the network with its content unchanged, i.e. as data packet 1262F at time t.sub.2, and as data packet 1263D at time t.sub.3. Similarly at time t.sub.3, data packet 1262J, comprising data segment 2A, remains unchanged in its content as data packet 1263G.

(591) To represent a data packet that is temporarily held in a media node, FIG. 91C illustrates the data packet moving from a given media node to the same media node in successive increments of time. For example, between time t.sub.3 and time t.sub.4, data packet 1263E comprising data segment 2F, the same as its predecessor data packet 1262G, is shown to move from media node M.sub.a,s to media node M.sub.a,s i.e. the packet is stationary. Although stationary data packet's state, encryption, and scrambling may change to reflect an updated time, the schematic's depiction of the content of data packet 1263E traveling from source media node M.sub.a,s to an identical destination media node M.sub.a,s at time t.sub.4 means it is held in memory by media node M.sub.a,s.

(592) Similarly, between time t.sub.1 and time t.sub.4, data packet 1263F comprising data segments 2D and 2E, the same as its predecessor data packet 1262H, is shown to move from media node M.sub.a,d to media node M.sub.a,d, again meaning the packet is stationary and held temporarily in memory. At time t.sub.4 incoming data packet 1263D is mixed in media node M with data packet 1263E, which has been held in memory there since time t.sub.3 resulting in new merged data packet 1264A, comprising concatenated data segments 2B, 2C and 2F. This new data packet 1264A remains held in media node M M.sub.a,s awaiting more incoming data. Meanwhile at time t.sub.4 in media node M.sub.a,d, data packets 1263F and 1263G are mixed and routed to media node M.sub.a,s as data packet 1264B, comprising data segments 2A, 2D and 2E. At time t.sub.f, incoming data packet 1264B is mixed with stationary data packet 1264A waiting in media node M.sub.a,s since time t.sub.4, creating original data packet 1056 sent to automobile 1255.

(593) As described, in the methods shown in accordance with this invention, data may transit through the SDNP cloud or be held stationary in a specific media node awaiting the arrival of incoming data before proceeding.

(594) Transport Command & Control

(595) In order for a media node to know how to process incoming data packets, it must somehow obtain information regarding the algorithms, numeric seeds, and keys to be used in scrambling, unscrambling, encrypting, decrypting, mixing, splitting, inserting and deleting junk, and parsing data packets. This important information can be passed in variety of means or some combination thereof, including Passing shared secrets to the media node as part of SDNP software installation or revisions, Passing control data through the media nodes prior to sending content, Passing control data through the media nodes as part of the data packet, Passing control data through a data channel separate from the media nodes that are communicating the information, e.g. through a network signaling server operating in parallel to the media nodes, Storing information regarding the identity of devices connected to the SDNP network and their corresponding IP or SDNP addresses on SDNP name servers separate from signaling servers or servers operating as media nodes carrying content.

(596) For example, as shown in FIG. 92A, at time t.sub.3 corresponding to state 993 data packet 1262B, comprising data segment 1B, data packet 1262C, comprising data segments 1C and 1F, and data packet 1262H comprising unrelated data segments enter media node M.sub.a,d. Upon entering the media node, the incoming data packets 1262B, 1262C and 1262H, which for clarity are shown in unencrypted form, are first processed by decryption and unscrambling operations. The data packets 1262B, 1262C and 1262H are then mixed including de-junking, i.e. removing junk bits, to produce output data packet 1263B, comprising data segments 1B, 1C and 1F. In order to perform this task, computer server 1220D, which is the host for media node M.sub.a,d, must first obtain certain information relating to the times and corresponding states used to create the incoming data packets. This information can be contained in the data packet as a header or sent in advance to the media node from a signaling node or another media node. As described in the table of FIG. 91B, these incoming data packets were last encrypted at time t.sub.2. The packets were last scrambled either at time t.sub.1, corresponding to state 1301A, or possibly at time t.sub.2, corresponding to state 1301B. This information must be delivered to node M.sub.a,d for it to properly process the incoming data in accordance with the conditions used to create the data packets. The state information at times t.sub.1 and t.sub.2 is used to create corresponding D-keys 1306A and 1306B needed for packet decryption of the incoming packets using D.sub.1 key generator 1305A and D.sub.2 key generator 1305B. The decryption key generators are realized using software located in a DMZ server attached to communication node M.sub.a,d. The general operation and generation of encryption and decryption keys were described in the background of this disclosure. Unlike static encryption, encryption in the SDNP network is dynamic, meaning that the only way to create the proper decryption key is to know when the file was encrypted. This information is conveyed as a time or state delivered along with the incoming data packet, or alternatively before the packet arrives, and used to select the appropriate encryption algorithm to generate the associated decryption key. The encryption algorithms and their associated decryption key generators are stored as shared secrets in a secure DMZ server attached to communication node M.sub.a,d.

(597) Although the data packets may be encrypted, for the sake of illustration, the data packets are shown in their unencrypted form. The same state information is also employed by numeric seed generator 1303 to produce corresponding numeric seeds 1304A and 1304B to determine the algorithms used at times t.sub.1 and t.sub.2 to create the data packets. The numeric seeds can be generated in two ways. In one case the seeds are generated using software located in the DMZ servers attached to media nodes where scrambling, mixing and encryption of the communicated data packets occurred. In such cases the seeds must be delivered to communication node M.sub.a,d prior to the data packet's arrival.

(598) In the other case, the time of the incoming packet's creation is delivered to communication node M.sub.a,d either as part of the incoming data packet's header or in a separate packet delivered in advance of the data. The time is then fed into numeric seed generator 1303 located within the DMZ server attached to communication node M.sub.a,d. Regardless of where they are generated locally or at the source and then delivered, the generated numeric seeds are fed into selector 1307, comprising tables of scrambling algorithms 1308A, mixing algorithms 1308B, and encryption algorithms 1308C. Aside from the seed or state information associated with the data packets, i.e. contained within the packet's header or delivered prior to the data packet, the algorithms used to create the incoming data packets are not carried by or contained within the packet itself but instead are present locally either within the media node M.sub.a,d or in a secure server to which the media node M.sub.a,d has access. These algorithms, stored locally as shared secrets for a specific region 1302A, in this case zone Z1, are shared with every media node in the same zone. By knowing the time and state when a data packet was created, the media node M.sub.a,d is able to determine how each of the packets 1262B, 1262C and 1262H was created and how to undo the process to recover the plaintext data of each of the packets 1262B, 1262C and 1262H, e.g. how to decrypt an encrypted packet, unscramble a scrambled packet, etc. The use of shared secrets, as well as how they are distributed, is described later in the application.

(599) The decryption keys 1306A and 306B work together with the selected encryption algorithm 1309C to decrypt ciphertext into plaintext. Specifically, the encryption algorithm 1309C represents a sequence of mathematical steps that may be used to convert a data packet from ciphertext into plaintext. The decryption keys 1306A and 1306B then select a specific combination of those steps that is to be used in decrypting the packet, each one corresponding to the state or time when the incoming data packets were last encrypted. If both incoming packets were encrypted at the same time, only a single decryption key is needed. While the reference above is to encryption algorithm 1309C, it will be understood that an encryption algorithm defines its inversea decryption algorithm. With the exception of certain types of encryption using asymmetric keys, most of the algorithms are symmetric, meaning that the inverse of the algorithm used to encrypt or scramble a data packet can be used to decrypt or unscramble the data packet and restore its original content. In the specific example shown in FIG. 92A, for each time and state corresponding to incoming data packets 1262B, 1262C and 1262H, selector 1307 outputs a selected encryption algorithm 1309C needed for decrypting the incoming packet, a selected scrambling algorithm 1309A needed to unscramble the incoming packet, and a selected mixing algorithm 1309B needed to combine the packets into a certain order and remove junk data. As such, the encryption, scrambling, and mixing algorithms selected by selector 1307 are used to perform decryption, unscrambling, and mixing operations, respectively, on data packets 1262B, 1262H and 1262C by computer server 1220D at media node M.sub.a,d. How the data is processed by the media node therefore depends both on the time and state of the incoming data packet and on the algorithms chosen. For example, selected mixing algorithm 1309B may arrange the incoming packets to be concatenated into a long packet in a sequence of decreasing time based on when the packet originated, e.g. with the oldest packet being placed at the front of the long packet and the newest data packet placed at the back. Or alternatively, the data can be arranged in chronological sequence of data segments as shown in data packet 1263B, i.e. data segment 1B before 1C, data segment 1C before 1F, etc. The processing of incoming data packets therefore requires time and state information pertaining to the creation of the incoming packets, not the current time or present state. Without first intercepting the state and time information of incoming packets, even a hacker gaining access to the algorithm tables and current states cannot decode, decipher, read or interpret a media node's incoming data. As stated previously, the selection of the algorithms by selector 1307 and key generation by key generators 1305A and 1305B depends on the geographical region or subnet where the data packets were created, shown in the example as zone info 1302A as zone Z1. The use of zones will be described further later in this disclosure.

(600) In contrast to the previous illustration showing control of incoming data packets, the control of outgoing data packets, shown in FIG. 92B depends, not on past times, and states, but on the current time and its corresponding state. As shown, at time t.sub.3 and its corresponding state 1301C, numeric seed generator 1303 produces numeric seed 1304C used by selector 1307 to select the corresponding algorithms for splitting, scrambling and encryption from tables of scrambling algorithms 1308A, mixing algorithms 1308B, and encryption algorithms 1308C. Since mixing algorithm 1308B is commonly a symmetric function, the inverse of the algorithm employed for mixing is used for splitting, in this case splitting the long data packet into multiple packets ready for transport. In dual-channel or tri-channel communication, the destinations for all the generated packets are communicated to the node from a signaling server managing packet routing. In single-channel communication, the media nodes themselves must emulate the signaling server function, mapping their own route between callers.

(601) The same state information 1301C is fed into E.sub.3 key generator 1305C to produce E-key 1306C needed for encrypting outgoing data packets and into seed generator 1303 to produce the seed 1304C that is used to select the encryption algorithm 1309C from the table 1308C. The E.sub.3 key works together with the selected encryption algorithm 1308C to encrypt plaintext into ciphertext. Specifically, the encryption algorithm represents a sequence of mathematical steps that may be used to convert a data packet from plaintext into one of millions, billions, or trillions of possible ciphertext results. The encryption key then selects a specific combination of those steps that is to be used in encrypting the packet.

(602) In symmetric key cryptography, such as the Advanced Encryption Standard or AES, described in http://en.wikipedia.org/wiki/advanced_encryption_standard, the key used to encrypt the file is the same key used to decrypt it. In such an instance, it is beneficial to generate the key locally as a shared secret contained within each media node, e.g. using E.sub.3 key generator 1305C. If a symmetric key must be supplied to a media node over a network, it is beneficial to deliver the key over a different communication channel than the media, i.e. the data packets and content, uses. Multi-channel communication is discussed later in this application.

(603) Other means to improve secure delivery of a symmetric key is to supply it to the media nodes at a time unrelated to the communiqu? itself, e.g. one week earlier, to encrypt the key with another layer of encryption, or to split the key into two pieces delivered at two different times. Another method employs using a key splitting algorithm in the E.sub.3 key generator 1305C where part of the key remains locally in every media node as a shared secret, i.e. never present on the network, and the other portion is delivered openly. Security is enhanced because a cyber-pirate has no way to determine how many bits the real key is because they can only see a portion of the key. Not knowing the length of the key renders guessing the right key virtually impossible because the key length and each of the key's elements must be guessed.

(604) In the case of an asymmetric or public key algorithm, E.sub.3 key generator 1305C concurrently generates a pair of keysone for encryption, the other for decryption based on the state 1301C or upon time t.sub.3. The decryption key is retained in the media node as a shared secret while the encryption key is safely and openly forwarded to the media node preparing to send a data packet to it. One complication of using symmetric keys in real time networks is that the encryption key needs to be generated and forwarded to all the media nodes prior to launching the data packet containing content on the media channel, otherwise the data packet may arrive before the key to decrypt it and the data go stale, i.e. become too late to use. Descriptions of the use and management of asymmetric and public encryption keys is available in numerous texts and online publications such as http://en.wikipedia.org/wiki/public-key_cryptography. While public key encryption is known technology, the disclosed application comprises a unique integration of cryptography into a real time network and communication system.

(605) Algorithms, numeric seeds, and encryption keys are all generated for the current subnet zone 1307A, in this case zone Z1. Based on this zone and the current time t.sub.3, encryption key 1306C, along with selected splitting algorithm 1309B, selected scrambling algorithm 1309A and selected encryption algorithm 1309C, is supplied to media node M.sub.a, hosted on computer server 1220D to produce two outputsoutput data packet 1263C comprising unrelated data segments sent onward at time t.sub.3 and output data packet 1263B comprising data segments 1B, 1C and 1F to be held until time t.sub.4 before routing to the next media node may continue. Instructions on whether to hold a data packet or data segment temporarily or send it on to the next media node immediately can be delivered to the media node in several ways. In one case the incoming data packet can embed instructions to hold it and till what time or for what precondition. Alternatively a signaling server, i.e. another communications channel, can give instructions to the media node what to do. The use of signaling servers in multi-channel secure communication is described later in this disclosure.

(606) As shown in FIG. 93, in order to select an algorithm from a table of algorithms, which could be scrambling/unscrambling, encryption/decryption or mixing/splitting algorithms, selector 1307 must search through a list of algorithms and memory addresses 1308D, comparing them to an address 1304D generated by seed generator 1303 from time t.sub.x and corresponding current state 1301D. When the state-generated address 1304D matches an item in algorithm table 1308D, the selected algorithm 1309D is output from the search routine for use. For example if seed generator 1303 generates an address 1304D having a value of 356, then selector 1307 will identify the matching item from the table, namely phase shift mod 2 and output it as selected algorithm 1309D.

(607) To prevent systematic tracking, the list of algorithms and their corresponding memory addresses is reshuffled regularly, e.g. daily or hourly, so that the same address does not invoke the same algorithm even if it accidentally repeats. As shown in FIG. 94, the algorithm tables for day 318 in zone Z1 comprise algorithm address table 1308D used for scrambling and unscrambling in zone Z1 on day 318, i.e., algorithm address table 1308E used for splitting or mixing data packets in zone Z1 on day 318, i.e., and algorithm address table 1308F table used for encryption or decryption in zone Z1 on day 318. Then, on a prescribed event date 1311 and time 1310, re-assign address operation 1312 shuffles, i.e. mixes up, the lists of algorithms and addresses, producing three new tables comprising algorithm address table 1308G for scrambling and unscrambling in zone Z1 on day 319, a second tablealgorithm address table 1308H for mixing and splitting in zone Z1 on day 319, and a third table for encryption and decryption in zone Z1 on day 319, i.e. algorithm address table 1308J. As shown for instance, on day 318, transpose mod 5 has a corresponding memory address 359, but one day later the address changes to 424. In this manner, the conversion table between addresses and algorithms is shuffled to avoid hacking.

(608) Zones and Bridges

(609) In order to communicate globally while preventing a hacker or cyber-pirate from gaining access to the entirety of the SDNP cloud and network, in another embodiment of this invention, the SDNP communication network is subdivided into zones. Herein, a zone represents a sub-division of the network, i.e. a subnet where each zone has its own unique command, control, and security settings including distinct and separate algorithms and algorithm tables that define mixing and splitting, scrambling and unscrambling, and encryption and decryption used in the zone as well as separate encryption keys and distinct numeric seeds. Naturally, communication servers running the SDNP software within the same zone share the same zone settings, operating in a manner completely agnostic to what zone it is in.

(610) Each subnet can comprise different server clouds running the SDNP software hosted by different ISPs or hosting companies, e.g. Microsoft, Amazon, Yahoo, or may comprise private hosted clouds or network address translators (NATs), such as rented private clouds comprising dark fiber dedicated bandwidth. It is also beneficial to treat carriers providing last-mile service such as Comcast northern California, local PSTN, or local cell phone connections as separate zones. The key benefit of employing zones is, in the worst-case scenario where a genius cyber-pirate temporally defeats the SDNP security provisions, to limit the geographic scope of their assault to a smaller subnet, preventing access of end-to-end communications. In essence, zones contain the damage potential of a cyber assault.

(611) An example of the use of zones is illustrated in FIG. 95A where cloud 1114 comprising computer servers 1118 running SDNP software is divided into two subnets, subnet 1318A comprising zone Z1 and subnet 1318C comprising zone Z2. As shown, Subnet 1318A comprises SDNP media nodes M.sub.a,w, M.sub.a,s, M.sub.a,j, M.sub.a,b, M.sub.a,q, and M.sub.a,f, along with M.sub.b,d and M.sub.b,h, while subnet 1318C comprises SDNP media nodes M.sub.c,j, M.sub.c,n, M.sub.c,v, M.sub.c,u, and M.sub.c,z, also along with media nodes M.sub.b,d and M.sub.b,h. While the media nodes with the leading subscript a, i.e. M.sub.a, . . . are unique to zone Z1 and the media nodes with the leading subscript c, i.e. M.sub.c . . . are unique to zone Z2, the media nodes M.sub.b,d and M.sub.b,h, hosted by computer servers 1220D and 1220H, are unique in that they are shared by both subnets 1318A and 1318C. The SDNP software that runs on computer servers 1220D and 1220H must understand how to communicate with other media nodes in both zone Z1 and in zone Z2. Such devices, act as bridges between two subnets, and necessarily must translate data from zone Z1 secured files into data formatted in accordance with zone Z2 secured files, and vice versa.

(612) The translation function performed in a bridge media node such as bridge media node M.sub.b,d is illustrated in FIG. 95B, which depicts the data flow from zone Z1 to zone Z2 where DUM operation 1210 within bridge computer server 1220D, which hosts bridge media node M.sub.b,d, performs decryption, unscrambling and mixing for subnet 1318A, zone Z1, using algorithm tables 1308K, to create a long packet which it transfers to SSE operation 1213, also within media node M.sub.b,d, which performs splitting, scrambling and encryption for subnet 1318C, zone Z2, using algorithm tables 1308L. The full duplex version of the bridge media node M.sub.b,d is shown in FIG. 95C, which shows that bridge media node M.sub.b,d performs bidirectional data transfer and translation from zone Z1 to zone Z2, and vice versa. For data translation from zone Z1 to zone Z2, SDNP bridge computer server 1220D, which is the host for bridge media node M.sub.b,d, performs DUM operation 1210 on the data packets as they leave zone Z1 (subnet 1318A) followed SSE operation 1210 on the data packets as they enter zone Z2 (subnet 1318C). Conversely, for data translation from zone Z2 to zone Z1, SDNP bridge computer server 1220D performs DUM operation 1210 on the data packets as they leave zone Z2 (subnet 1318C) followed by SSE operation 1213 on the data packets as they enter zone Z1 (subnet 1213A). All four data operations performed at bridge media node M.sub.b,d are performed in software residing in the same computer server host, in this case computer server 1220D.

(613) The fully integrated SDNP bridge media node M.sub.b,d illustrated in FIG. 95C, performs both DUM and SSE operations for two different zones, i.e. zone Z1 and zone Z2, all in shared computer server 1202D. Such a fully integrated implementation can only realized if the two connected subnets are hosted within the same ISP or cloud. If the subnets, however, reside in different clouds, hosted by different service providers, as shown by subnets 1318A and 1318C in FIG. 95D, a communication bridge must be realized between two computer servers not residing in the same cloud. As shown, bridge communication link 1316B connects SDNP bridge media node M.sub.b,h operating in zone Z1 to SDNP bridge media node M.sub.b,u operating in zone Z2, but zone Z1 operates in cloud 1114 while zone Z2 operates in a different cloud 1315. Utilizing the same method shown previously in FIG. 95C becomes problematic in the multi-cloud case because bridge communication link 1316B traveling between the clouds will be unsecured and vulnerable to sniffing and cyber-assaults. FIG. 95E illustrates such a case where DUM operation performed by bridge media node M.sub.b,h hosted by computer server 1220H in subnet 1318A and zone Z1 sends data packets through bridge communication link 1316B to bridge media node M.sub.b,u hosted by computer server 1220U in subnet 1318C and zone Z2 for translation, but because the communication is an unencrypted unscrambled long packet output from the DUM operation of bridge media node M.sub.b,h, the cloud-to-cloud hop is unsecured and exposed to cyber-assaults.

(614) The solution to this problem is to employ the two full-duplex bridge interface media nodes, one in each cloud as shown in FIG. 95F with secure communication transport between the interfaces. In zone Z1 to zone Z2 communication, data packets incoming from zone Z1 within subnet 1318A are converted into single-channel zone Z2 data, including scrambling and encryption. This function requires media node M.sub.b,d to have access to both zone Z1 and zone Z2, numeric seeds, encryption keys, algorithm tables, and other security items. All the processing is performed in computer server 1220D located within subnet 1318A, not in the zone 72 destination cloud. The secure data is then transferred from bridge interface media node M.sub.b,d in subnet 1318A to bridge interface media node M.sub.b,u in subnet 1318C using secure bridge communication link 1316A. Upon arrival in bridge interface media node M.sub.b,u the data packets are processed in accordance with zone Z2 information and sent onwards into subnet 1318C.

(615) Conversely, in zone Z2 to zone Z1 communication, incoming data packets from zone Z2 and subnet 1318C to media node M.sub.b,u are converted into single-channel zone Z1 data including scrambling and encryption. This function requires media node M.sub.b,d to have access to both zone Z1 and zone Z2, numeric seeds, encryption keys, algorithm tables, and other security items. All packets are processed in computer server 1220U located within subnet 1318C, not in the zone Z1 destination cloud. The secure data is then transferred from bridge interface media node M.sub.b,u in subnet 1318C to bridge interface media node M.sub.b,d in subnet 1318A using secure bridge communication link 1316C. Upon arrival in bridge interface media node M.sub.b,d the data packet is processed in accordance with zone Z1 information and sent onwards into subnet 1318A. Although secure bridge communication links 1316A and 1316C are depicted as separate lines, the lines represent distinct communication channels at the network layer 3 and are not intended to correspond to separate wires, cables, or data link at a hardware or PHY layer 1 description. Alternatively, a receiving bridge node can translate the data from the Z1 sending zone to the Z2 receiving zone, so long as the receiving bridge node hold shared secrets for both Z1 and Z2 zones.

(616) SDNP Gateway Operation

(617) The previous section describes a bridge as any media node or pair of media nodes communicating between separate subnets, networks, or clouds. In a similar manner, a SDNP gateway media node disclosed herein provides a communication link between the SDNP cloud and a client's device, e.g. a cell phone, automobile, tablet, notebook, or IoT device. Gateway media node operation is illustrated in FIG. 96A, where computer server 1220F in SDNP cloud 1114 hosting SDNP media node M.sub.b,f acts as a SDNP gateway media node between subnet 1318A and last-mile connection 1318D to tablet 33. Unlike subnet 1318A, last-mile connection 1318D may occur over the Internet, a private cloud, a cable TV connection, or a cellular link. In the last-mile routing cannot be controlled precisely as it is in subnet 1318A. For example, gateway media node M.sub.b,f links to server 65A by connection 1317 but beyond that point, routing to public WiFi base station 100 is controlled by local Internet routers. The WiFi radio link 29 from WiFi antenna 26 to tablet 33 is also controlled by a local device, often located in an airport, hotel, coffee shop, convention center, amphitheater, or other public venue.

(618) Alternatively, the last mile may comprise a wired link to LTE base station 17, with a radio link 28 from antenna 18 to tablet 33. Because of its uncertain routing and access, it is beneficial not to share security settings or secrets used in the SDNP cloud with devices used in last-mile routing to a client. As such, last-mile link 1318D does not have access to zone Z1 information, but instead uses a separate zone U2 to manage security settings. In order to link the cloud 1114 and the last-mile, gateway media node M.sub.b,f necessarily has access to both zone Z1 and zone U2 security settings, facilitating communication between cloud interface 1320 and client interface 1321. To provide secure last-mile communication, the client, in the example shown tablet 33, must also be running SDNP client software application 1322.

(619) SDNP gateway node M.sub.b,f comprises cloud interface 1320, facilitating communication among the media nodes within cloud 1114, and client interface 1321 facilitating communication across the last mile. As shown in FIG. 96B, cloud interface 1320 comprises two data paths, i.e. SSE 1213 and DUM 1210. Client interface 1321 shown in FIG. 96C also comprises two data pathsone for data flow from the gateway to the client, the other for data flow in the reverse direction from the client to the gateway. Specifically, data flow from the gateway to the client sequentially involves single-route splitting operation 1106 used to insert junk data into the data stream, followed by packet scrambling 926 and finally encryption 1026. In the opposite direction, data flow from the client to the gateway sequentially involves decryption 1032, packet un-scrambling 928, and single-route mixing operation 1089 used to remove junk data from the data stream.

(620) The roles of mixing and splitting operations in single route communication such as the last mile are two-fold. Firstly, and importantly, the real time data stream is divided into numerous sequential sub-packets each with their own identifying tags and possibly of varying length to defy easy detection. The resulting serial data stream therefore requires some data sub-packets to be held temporarily while the first packets are sent. Since communication data rates occur in the SDNP cloud at hundreds of gigabits per second, serialization is nearly instantaneous, requiring only nanoseconds. Within last mile communication the data rate is slower (but in modern systems is still very fast), e.g. two gigabits per second. No added delay occurs because WiFi, 4G/LTE, DOCSIS 3 and Ethernet all transmit data serially anyway.

(621) The second need for single-channel mixing, the single-route mixing operation is also used to inject junk data into the sub-packets in varying ways to confound analysis in a manner previously described in regards to FIG. 67J.

(622) As shown in FIG. 96D, to communicate securely over the last mile, the client must run client 1322 software. In a cell phone or tablet, this client software must run on the device's operating system, e.g., Android or iOS. In a desktop or notebook computer, client software runs on the computer's operating system, e.g., MacOS, Windows, Linux, or Unix. In the event that communication occurs with a consumer device such as IoT incapable of hosting the SDNP client software, a hardware device with embedded client firmware may be used as an interface. The communication related functions performed by client 1322 comprise processing of incoming data packets by decryption operation 1032, packet unscrambling 928, and de-junking using single route mixing operation 1089 to recover the packets payload. The content is then used in applications 1336 including data used for an audio CODEC, MPEG files, images, non-media files and software.

(623) The communication related functions performed by client 1322 for outgoing data packets comprise inserting junk data in single-route splitting operation 1026, packet scrambling 926, and finally encryption operation 1106 to prepare the data packet for last mile communication to the gateway. Within client 1322 software, single-route mixing 1089 algorithmically removes junk data from the incoming data stream while the role single-route splitting 1026 is to insert junk data into the data packets.

(624) Operation of secure SDNP gateway node M.sub.b,f is further detailed in FIG. 97A, where cloud interface 1320 and client interface 1321 receive incoming data packets from media node M.sub.a,h, performing decryption, unscrambling, and mixing using DUM operation 1210 in accordance with zone Z1 security settings, resulting in exemplary data packet 1330 representing unscrambled plaintext. The data packet 1330 is then forwarded into client interface 1321, also operating within gateway media node M.sub.b,f, which inserts junk packets 1053 as part of single-route splitting operation 1106 used for inserting junk 1053 into the data packets, but using zone U2 security settings, not the zone Z1 security setting that are used by the cloud. The data packet is next scrambled using scrambling operation 926, again utilizing last-mile specific zone U2 security settings to produce data packet 1329.

(625) In the example shown, scrambling operation 926 utilizes an algorithm whereby the actual data segments are scrambled but every other data segment comprises a junk data segment. Next, encryption operation 1026 is also performed in client interface 1321, also using zone U2 security settings, to produce outgoing ciphertext 1328. The data fields may be individually encrypted separately from the junk data (as shown), or in an alternative embodiment, the entire data packet 1329 may be encrypted to form one long ciphertext. The encrypted data packet is finally forwarded, i.e. exported, through a single communication channel to the client.

(626) Concurrently, data received via the last-mile single-channel routing from the client comprising scrambled ciphertext 1327 is decrypted by decryption operation 1032, using zone U2 security settings including algorithms, decryption keys, etc., to produce scrambled plaintext data packet 1326, comprising a combination of scrambled data segments of data interspersed with junk data segments. In one embodiment of this invention, the junk packets of this incoming data packet 1326 are not positioned in the same slots as outgoing scrambled plaintext data packet 1329. For example, in the example of outbound data, every other packet comprises junk data, while in the incoming data packet every 3.sup.rd and 4.sup.th slot, and integer multiples thereof, contain junk data.

(627) The scrambled plaintext data packet 1326 is next processed using zone U2 security settings by packet unscrambling operation 928 and then by mixing operation 1089 to restore the original data order and to remove the junk packets, i.e. to de-junk 1053 the data, resulting in unencrypted unscrambled data packet 1325. This data packet is then passed from client interface 1321 to cloud interface 1320, to perform cloud specific splitting, scrambling and encryption using SSE operation 1213, before forwarding the resulting fragmented data in different data packets for meshed routing to media node M.sub.b,h and others.

(628) As further illustrated in FIG. 97B, the SDNP gateway media node M.sub.b,f utilizes software to facilitate full-duplex communication in both cloud interface 1320 in accordance with zone Z1 security settings, and in client interface 1321 in accordance with zone U2 security settings. The last-mile connection 1355 from client interface 1321 to tablet 33 via LTE base station 27, LTE radio tower 18, and radio link 28 is secure because the communication is scrambled and encrypted, and junk data has been inserted into the data packets. To interpret the incoming data packets and be able to securely respond, the client device, in this case tablet 1322, must be running SDNP-enabled device application software 1322.

(629) The processing of data packets in the SDNP client interface is further detailed in FIG. 98, where client node C.sub.2,1 securely communicates with SDNP gateway media node M.sub.b,d by the full duplex data exchange between client interface 1321 and SDNP client 1322, both being in security zone U2. In operation, data packets arriving from client interface 1321 are decrypted in decryption operation 1032, unscrambled in unscrambling operation 928, and de-junked using splitting operation 1089 before being processed by applications 1336. Conversely, the output of applications 1336 is processed by mixing operation 1026 to insert junk, then scrambled in scrambling operation 926 and encrypted in encryption operation 1106 before the data is forwarded to client interface 1321.

(630) Using the methods disclosed herein, secure communication between two or more clients, statically or dynamically routed across a meshed network may employ any combination of mixing, splitting, encryption and scrambling algorithms managed in separate zones with separate keys, distinct numeric seeds, and dissimilar security-related secrets. As illustrated in FIG. 99A, a meshed network comprising computer servers 1118 running software-based SDNP media nodes includes computer servers 1220F and 1220D, hosting gateway media nodes M.sub.b,f and M.sub.b,d. Security within subnet 1318A is managed by the security settings for zone Z1. Gateway media node M.sub.b,d connects to client node C.sub.1,1, hosted on an external device, in this case cell phone 32, accessed through last-mile link 1318E. Security on last-mile link 1318E is governed by the security settings for zone U1. Similarly, gateway media node M.sub.b,f connects to client node C.sub.2,1, hosted on tablet 33 and connected through last-mile link 1318D. Security for the last-mile link 1318D is governed by the security settings for zone U2.

(631) As shown, communication using encryption operation 1339, symbolized by a padlock, provides security throughout the network and over the last mile links. To secure the last mile, encryption is necessarily performed within the client devices. Optionally, packets may be re-encrypted or double encrypted by the gateway media nodes, or in another embodiment, decrypted and re-encrypted by every media node in the meshed transport network. One embodiment of the invention disclosed herein is to facilitate multi-level security. For example, in FIG. 99A the last-mile communication links 1318D and 1318E rely solely on encryption, i.e. single level or 1-dimensional security. Within network 1318A, communication utilizes 2-dimensional or dual-level security, combining encryption with meshed network operation involving static splitting, multi-route transport, and mixing. In the event that the security settings vary with time, i.e., dynamically, as data packets transit across the network, an added level of security is realized, i.e. 2-dimensional or dual-level security over the last mile and 3-dimensional security within the SDNP cloud.

(632) As shown in FIG. 99B, adding scrambling into network 1318A augments security, into a higher grade of multi-level security combining meshed transport and encryption with scrambling. Specifically, in this approach, communication from client node C.sub.2,1 to client node C.sub.1,1 involves adding scrambling operation 926 into gateway media node M.sub.b,f and unscrambling operation 928 into gateway media node M.sub.b,d. In communication from client node C.sub.1,1 to client node C.sub.2,1, encrypted data packets from client node C.sub.1,1 are first decrypted, and then split for multi-route transport, scrambled by scrambling operation 926, and encrypted in gateway media node M.sub.b,d. After transport through network 1318A, the data packets are decrypted, unscrambled using unscrambling operation 928, and then mixed. While this approach provides multi-dimensional security within network 1318A it does not provide multi-level security in the last mile, which employing single-channel transport without scrambling relies solely on encryption for its security.

(633) Another embodiment of this invention, shown in FIG. 99C, extends the multi-level security technique combining encryption and scrambling to cover both network 1318A and last-mile connection 1318D to client node C.sub.2,1. As such, communication from client node C.sub.2,1 to client node C.sub.1,1 includes scrambling operation 926 within client node C.sub.2,1 and unscrambling operation 928 within gateway media node M.sub.b,d. Communication from client node C.sub.1,1 to client node C.sub.2,1 utilizes scrambling operation 926 in gateway media node M.sub.b,d and unscrambling operation 928 hosted in client node C.sub.2,1. Last-mile connection 1318E between client node C.sub.1,1 and gateway media node M.sub.b,d, however, relies solely on encryption. Such a case could occur where client node C.sub.2,1 is running SDNP security-enabled software application but client node C.sub.1,1, is only employing off-the-shelf encryption.

(634) Another embodiment of the invention, shown in FIG. 99D, extends scrambling and encryption for multi-dimensional security from client-to-client, i.e. from end to end. As such, communication from client node C.sub.2,1 to client node C.sub.1,1 involves adding scrambling operation 926 within client node C.sub.2,1 and unscrambling operation 928 within client node C.sub.1,1. Communication from client node C.sub.1,1 to client node C.sub.2,1 involves adding scrambling operation 926 within client node C.sub.1,1 and unscrambling operation 928 hosted in client node C.sub.2,1. In operation, client node C.sub.1,1 scrambles and encrypts any outgoing data packets and performs decryption and unscrambling on incoming data through SDNP-enabled software running in cell phone 32. Similarly, client node C.sub.2,1 scrambles and encrypts any outgoing data packets and performs decryption and unscrambling on incoming data through SDNP enabled software running in tablet 33. Together, they facilitate end-to-end secure communication with dual-layer or 2-dimensional security, i.e. comprising encryption and scrambling, in last-mile connections 1318D and 1318E, and 3-dimensional or tri-layer security within meshed network 1318A through meshed and multi-route transport. In the event that the security settings vary with time dynamically as data packets transit across the network, an added level of security is realized, i.e. 3-dimensional or tri-level security over the last mile and 4-dimensional security within the SDNP cloud.

(635) A possible weakness of this implementation is that the same scrambling methods and numeric seeds used by the client are also used to secure the SDNP cloud. As a result, the security settings for zones U2, Z1 and U1 are necessarily shared, risking the entire network and routing to discovery through last-mile cyber-assaults. One method available to counteract exposed cloud security settings is illustrated in FIG. 99E, where last-mile connection 1318D utilizes scrambling using zone U2 security settings while the cloud, uses zone Z1 security settings for its scrambling. In this example the client node C.sub.2,1, running as an application in tablet 33, facilitates scrambling 926 according to zone U2 security settings. Gateway media node M.sub.b,f hosted by computer server 1220F unscrambles the incoming data packet using zone U2 security settings, then scrambles the data packets again using zone Z1 security settings for transport over meshed network 1318A. In this manner, the cloud's zone Z1 security settings are never revealed in last-mile connection 1318D.

(636) A further improvement on multi-level security is illustrated in FIG. 99F, where scrambling and encryption occur using different security settings in three distinct zoneslast-mile connection 1318D connecting the client node C.sub.2,1 to gateway media node M.sub.b,f, which utilizes zone U2 security settings, meshed network 1318A including gateway media nodes M.sub.b,f and M.sub.b,d, which utilizes zone Z1 security settings, and last-mile connection 1318E, connecting gateway media node M.sub.b,d to client node C.sub.1,1, which utilizes zone U2 security settings. This approach provides end-to-end security with end-to-end encryption, end-to-end scrambling, and meshed routing in the cloud representing dual-layer or 2-dimensional security in last-mile and tri-layer or 3-dimensional security in the cloud. In the event that the security settings vary with time dynamically as data packets transit across the network, an added level of security is realized, providing 3-dimensional or dual-level security over the last-mile and 4-dimensional security within the SDNP cloud.

(637) In communication from client node C.sub.2,1 to client node C.sub.1,1, i.e. from tablet 33 to cell phone 32, a SDNP application running on client node C.sub.2,1 scrambles the outgoing data packet using scrambling operation 926 with zone U2 security settings followed by encryption. The single-channel data packet traversing last-mile connection 1318D is first decrypted and then unscrambled by unscrambling operation 928 performed by gateway media node M.sub.b,f, using zone U2 security settings. Using zone Z1 security settings, gateway media node M.sub.b,f then splits, scrambles and encrypts the data for meshed transport over network 1318A, using zone Z1 security settings. In gateway media node M.sub.b,d, the data packet is decrypted, unscrambled with unscrambling operation 928, and then mixed into a data packet for single-channel communication, using zone Z1 security settings. Gateway media node M.sub.b,d then scrambles and encrypts the single-channel data packet again, using zone U1 security settings, and then forwards the data on to client C.sub.1,1. An SDNP-enabled application running on cell-phone 32 decrypts and then unscrambles using unscrambling operation 928 the final packet delivered to its destination using zone U1 security settings.

(638) Similarly in the opposite direction, i.e. in communication from client node C.sub.1,1 to client node C.sub.2,1, i.e. from cell phone 32 to tablet 33, a SDNP application running on client node C.sub.1,1 scrambles the outgoing data packet using scrambling operation 926 with zone U1 security settings, followed by encryption. The single-channel data packet traversing last-mile connection 1318E is first decrypted and then unscrambled by unscrambling operation 928, performed by gateway media node M.sub.b,d, using zone U1 security settings. Using zone Z1 security settings, gateway media node M.sub.b,d then splits, scrambles and encrypts the data for meshed transport over network 1318A, using zone Z1 security settings. In gateway media node M.sub.b,f the data packet is decrypted, unscrambled with unscrambling operation 928, and then mixed into a data packet for single-channel communication using zone Z1 security settings. Gateway media node M.sub.b,f then scrambles and encrypts the single-channel data packet, using zone U2 security settings, and forwards the data to client node C.sub.2,1. An SDNP-enabled application running in tablet 33 decrypts and then unscrambles the data using unscrambling operation 928 and zone U2 security settings. The data packet is then delivered to the client, in this case tablet 33.

(639) As stated previously, all communications links shown carry encrypted data regardless of scrambling and mixing, as depicted by pad lock icon 1339. The detailed encryption and decryption steps are not shown for the purpose of clarity. In one embodiment, the data packets are decrypted and encrypted (i.e., re-encrypted) each time data traverses a new media node. In the very least, in every media node performing re-scrambling, incoming data packets are decrypted before unscrambling then scrambled and encrypted. A summary of the available multilayer security achievable with meshed transport, encryption, and scramblingall employing zone-specific security settingsis shown in the following table.

(640) TABLE-US-00010 Cloud Last Mile Security Method Security Security Meshed Routing in Cloud, No Encryption, 1-D None No Scrambling Meshed Routing, End-to-End Encryption, 2-D 1-D No Scrambling Meshed Routing, End-to-End Scrambling + 3-D 2-D Encryption Dynamic Meshed Routing, End-to-End 4-D 3-D Scrambling + Encryption Dynamic Meshed Routing, End-to-End 4-D 3.5-D Scrambling + Encryption + Junk

(641) As shown in the above table, adding dynamic changes to the encryption and scrambling during transport over time confers an added level of security by limiting the time in which a cyber-criminal has to sniff the packet and break the code to read a data packet. Dynamic changes can occur on a daily, hourly, or scheduled period or on a packet-by-packet basis, changes roughly every 100 msec. From the above table, it is also clear that the last mile is less secure than transport through the cloud.

(642) One means of augmenting the last-mile security is to dynamically insert junk data segments into the data stream, and even to send packets consisting entirely of junk, as decoys, wasting the computing resources of cyber-criminals by decoding worthless data. This improvement is represented as by the change from 3-D to 3.5-D, signifying that inserting junk data is not as good a security enhancement as that achieved through encryption, scrambling, and multi-route transport, but it is still an improvement, especially if the junk insertions vary over time, and differ in incoming and outgoing packets. Another important aspect to improve SDNP security in accordance with this invention is to employ misdirection, i.e. to obscure the real source and destination during packet routing, a topic discussed later in this disclosure.

(643) Delivery of Secrets, Keys, and Seeds

(644) SDNP-based secure communication relies on exchanging information between communicating parties that outside parties are not privy to or aware of or whose meaning or purpose they are unable to comprehend. Aside from the actual content of the data being transmitted, this information may include shared secrets, algorithms, encryption and decryption keys, and numeric seeds. A shared secret, as used herein, is information that only certain communicating parties know or share, e.g., a list of mixing, scrambling, and/or encryption algorithms, an encryption and/or decryption key, and/or a seed generator, number generator, or another method to select specific ones over time. For example, the selector 1307, shown in FIG. 92B, is a shared secret.

(645) Working in conjunction with shared secrets, numeric seeds, which may be based on a time and/or state, are then used to select specific algorithms, invoke various options, or execute programs. By itself, any specific numeric seed has no meaning, but when combined with a shared secret, a numeric seed can be used to communicate a dynamic message or condition across a network without revealing its meaning or function if intercepted.

(646) Similarly, to execute encrypted communication, encryption requires a specific algorithm agreed upon by the communicating parties, i.e. a shared secret, and the exchange of one or two keys used for encryption and decryption. In symmetric key methods, the encryption and decryption keys are identical. Symmetric key exchanges are resilient to attacks provided the key is long, e.g. 34 bits or 36 bits, and that the time available to break the cipher is short, e.g. one second or less. For any given encryption algorithm, the ratio of the number of bits used in a symmetric encryption key divided by the time in which the key is valid is a measure of the robustness of the encryption. As such, symmetric keys can be used in a dynamic network, provided that they are large and that the time available to break the encryption is short. As an alternative, encryption algorithms may be employed wherein the encryption and decryption keys are distinct, or asymmetric with one key for encryption and another for decryption. In open communication channels, asymmetric keys are advantageous because only the encryption key is communicated and the encryption key gives no information about the decryption key. Working in concert, the combination of symmetric and asymmetric encryption keys, numeric seeds, and shared secretsall varying over time dynamically, provides superior multi-dimensional security to SDNP communication. Numerous general references on cryptography are available, e.g. Computer Security and Cryptography by Alan G. Konheim (Wiley, 2007). Adapting encryption to real time communication is, however, is not straightforward and not anticipated in the available literature. In many cases, adding encryption to data communication increases latency and propagation delay, degrading the network's QoS.

(647) Shared secrets can be exchanged between client nodes and media nodes prior to an actual communiqu?, message, call, or data exchange. FIG. 100A illustrates how shared secrets can be distributed in conjunction with SDNP-executable code installation. Within zone Z1, secure software package 1352A comprises executable code 1351 and zone Z1 shared secrets 1350A, which may include seed generator 921, number generator 960, algorithms 1340, encryption key 1022, and decryption key 1030, or some combination thereof. Secure software package 1352A for zone Z1, including executable code 1351 and shared secrets 1350A, is delivered to the media servers 1118 in cloud 1114 and to both DMZ servers 1353A and 1353B. The installation of executable code 1351 in media nodes M.sub.a,b, M.sub.a,f and others hosted in servers 1118 occurs concurrently with the installation of the shared secrets for zone Z1, i.e. Z1 secrets 1350A, in separate computers referred to here as DMZ servers 1353A and 1353B.

(648) The term DMZ, normally an acronym for demilitarized zone, in this case means a computer server not directly accessible through the Internet. DMZ servers can control one or numerous network-connected servers functioning as media nodes, but no media server 1118 can access any DMZ serverDMZ servers 1353A, 1353B and any others (not shown). All software and shared secrets distribution occurs in secure communications valid for only a short duration as depicted by time clocked padlock 1354. If the software delivery is late, an SDNP administrator must reauthorize the download of the secure software package 1352A for zone Z1 after personally confirming the account holder's identity and credentials.

(649) To elaborate, the description of DMZ server as a computer server not connected directly to the Internet means that no direct electronic link exists between the Internet and the servers. While Z1 file 1352A may in fact be delivered to the server or server farm over the Internet, file installation into the DMZ requires the intervention of the account administrator of the server or server farm working in cooperation with the account holder. Before installing files into the DMZ, the account administrator confirms the identity of the account holder and the validity of the installation.

(650) After confirming the installation, the administrator then loads the file containing Z1 secrets into the DMZ server using a local area network (LAN) linking the administrator's computer directly to the DMZ server. The LAN is, therefore, not directly connected to the Internet, but requires authorized transfer through the administrator's computer after a rigorous authentication process. The installation of the shared secrets is unidirectional, the files being downloaded into the DMZ servers with no read access from the Internet. Uploading the DMZ content to the Internet is similarly prohibited, thereby preventing online access or hacking.

(651) The shared secret installation process is analogous to a bank account that is not enabled for online banking, but where only with the client's approval can a bank officer manually perform an electronic wire transfer. By denying Internet access, intercepting shared secrets would require a physical entry and on-location attack at the server farm, one where the LAN fiber must be identified, spliced, and intercepted precisely at the time of the transfer. Even then, the file being installed is encrypted and available for only a short duration.

(652) The same concept can be extended to multi-zone software deployment, shown in FIG. 100B, where an SDNP administration server 1355 is used to send a secure software package 1352A for zone Z1 to DMZ server 1353A, as zone Z1 secrets 1350A, and to media servers 1118 in cloud 1114, as executable code 1351. SDNP administration server 1355 is likewise used to distribute a secure software package 1352B for zone Z2 to DMZ server 1353B, as zone Z2 shared secrets 1350B, and to the media servers in cloud 1315, as executable code 1351. SDNP administration server 1355 also delivers a secure software package 1352C including the executable code 1351 to the bridge media nodes M.sub.b,f in SDNP cloud 1114 and M.sub.b,n in SDNP cloud 1315, and the shared secrets 1350C for both zones Z1 and Z2, to DMZ server 1353C. Bridge media nodes M.sub.b,f in SDNP cloud and M.sub.b,n in SDNP cloud 1315 receive the executable code 1351 directly from administration server 1355 and the zone Z1 and zone Z2 shared secrets from DMZ server 1353C. Since bridge media node M.sub.b,f performs a translation between Z1 and Z2 secrets, only it (and any other bridge server not shown) need access to both Z and Z2 shared secrets. Otherwise the nodes in zone Z1 require access only to zone Z1 shared secrets and the nodes in zone Z2 require access only to zone Z2 shared secrets

(653) It is important to highlight that while SDNP administration server 1355 supplies shared secrets to DMZ servers 1353A, 1353B and 1353C, SDNP administration server 1355 has no knowledge as to what happens to the shared secrets after delivery, nor does it perform any command or control influence over the shared secrets once delivered. For example, if a list of algorithms is shuffled, i.e. reordered, so that the address for a specific algorithm changes, SDNP administration server 1355 has no knowledge as to how the shuffling occurs. Likewise, SDNP administration server 1355 is not a recipient of numeric seed or key exchanges between communicating parties and therefore does not represent a point of control. In fact, as disclosed, no server in the entire SDNP network has all the information regarding a package, its routing, its security settings, or its content. Thus, the SDNP network is uniquely a completely distributed system for secure global communication.

(654) Delivery of shared secrets to a DMZ server, as shown in FIG. 101A, is performed in a strictly defined process whereby SDNP administration server 1355 establishes communication with DMZ server 1353A and goes through an authentication process to confirm if the computer is in fact an SDNP-authorized DMZ server. The process can be automated or can involve human interaction and verification of account owners in a manner similar to a bank transfer. In either case, only when authentication confirms the authenticity of DMZ server 1353A, is an electronic authorization certificate 1357 generated, allowing SDNP administration server 1355 to transfer its secrets and code to DMZ server 1353A. Once loaded, these settings are sent to media servers 1361, 1362, and 1363, instructing media nodes M.sub.1, M.sub.2, and M.sub.3, respectively how to process incoming and outgoing data packets.

(655) The same DMZ server 1353A can manage more than one media server, e.g. media server array 1360, or alternatively multiple DMZ servers can carry the same security settings and shared secrets. The media nodes may all be operating to carry media, content, and data cooperatively using timesharing, and load balancing. If the communication loading on media server array 1360 drops, media node M.sub.3 can be taken offline, indicated symbolically by open switches 1365A and 1365B, leaving media node M.sub.2 still operating, as indicated by closed switches 1364A and 1364B. The switches do not indicate that the input and the outputs of the particular server are physically disconnected but just that the server is no longer running the media node application, thereby saving power and eliminating hosting use fees for unneeded servers. As illustrated, one DMZ server 1353A can control the operation of more than one media server by downloading instructions, commands, and secrets from DMZ server 1353A to any server in server array 1360, but the converse is not true. Any attempt to gain information, to write, query, or inspect the contents of DMZ server 1353A from a media server is blocked by firewall 1366, meaning that the content of the DMZ server 1353A cannot be inspected or discovered through the Internet via a media node.

(656) An example of secure communication in accordance with this invention based on shared secrets is illustrated in FIG. 101B, where prior to any communication, shared secrets 1350A for zone Z1 were supplied by an administration server (not shown) to all DMZ servers in zone Z1, including DMZ servers 1353A and 1353B. Such shared secrets may include, without limitation, seed generator 921, number generator 960, algorithms 1340, encryption key 1022, and decryption key 1030. During communication between sending media node M.sub.S and receiving media node M.sub.R hosted by media servers 1118, DMZ server 1353A passes shared secrets to sending media node M.sub.s to prepare payload packet 1342 comprising data 1341 and state 920, describing the time payload packet 1342 was created. Before transmission from media node M.sub.S, payload packet 1342 is also encrypted, using encryption operation 1339, represented symbolically by a padlock.

(657) Upon receiving secure payload packet 1342, receiving media node M.sub.R decrypts packet 1342, using decryption key 1030 contained within shared secrets 1350A supplied by DMZ server 1353B, and then, using state information 920 specific to the data packet 1342, recovers data 1341. In an alternative embodiment, numeric seed 929 may also be sent a priori, i.e. before the communication of payload packet 1342, from sending media node M.sub.S to receiving media node M.sub.R as a numeric seed 929 with a temporary life. If it is not used within a certain period of time or if payload packet 1342 is delayed, the seed's life expires and it self-destructs, rendering media node M.sub.R unable to open payload packet 1342.

(658) Another example of secure communication in accordance with this invention, based on shared secrets combined with a seed and a key encapsulated within the packet being delivered, is illustrated in FIG. 101C. In this example, prior to any communication, shared secrets 1350A for zone Z1 are supplied to all zone-Z1 DMZ servers, including servers 1353A and 1353B. Such shared secrets may, without limitation, include seed generator 921, number generator 960, and algorithms 1340, but they do not include keys such as encryption key 1022, and decryption key 1030. During communication between sending media node M.sub.S and receiving media node M.sub.R hosted by media servers 1118, DMZ server 1353A passes shared secrets to sending media node M.sub.S to prepare payload packet 1342, comprising data 1341, state 920 (describing the time payload packet 1342 was created), and encryption key 1022 (which is used for encrypting future payload packets). Before routing, payload packet 1342 is encrypted using encryption operation 1339, represented symbolically by a padlock.

(659) Upon receiving secure payload packet 1342, receiving media node M.sub.R decrypts packet 1342, using decryption key 1030, which has a temporary life and was supplied a priori, i.e. before the communication of payload 1342, in a separate communication between sending media node M.sub.s and receiving media node M.sub.R. This earlier data packet may be secured by shared secrets such as another decryption, a dynamic algorithm, a numeric seed, or a combination thereof. If decryption key 1030 is not used within a certain period of time, or if data packet 1342 is delayed, the decryption key 1030 expires and self-destructs, rendering media node M.sub.R unable to open payload packet 1342. While decryption key 1030 can alternatively be included in payload packet 1342, this technique is not preferred.

(660) One way to avoid delivering all of the security-related information with the content is to split and separate the channel used to deliver command and control signals from the media communication channel used to deliver content. In accordance with this invention, such a dual-channel communication system, shown in FIG. 102, comprises a media channel carried by media servers and a command and control channel carried by a second network of computers, referred to herein as signaling servers. During communication, the signaling server 1365 running installed SDNP software operates as signaling node S.sub.1 for carrying command and control signals while the media servers 1361, 1362, and 1363 running installed SDNP software operate as media nodes M.sub.1, M.sub.2, M.sub.3 respectively for carrying content and media. In this manner, the media channel does not carry command and control signals and command and control signals need not be delivered over the media channel either combined with the payload or separately as an a priori data packet delivered in advance of the data packet containing the message content.

(661) In operation, packets are delivered to signaling node S.sub.1 describing the routing and security settings for media packets expected as incoming packets to server array 1360. These special purpose packets are referred to herein as command and control packets. During communication, the command and control packets are sent to media servers 1361, 1362, and 1363 instructing media nodes M.sub.1, M.sub.2, and M.sub.3, respectively how to process incoming and outgoing data packets. These instructions are combined with information residing within DMZ server 1353A. As previously described, the same DMZ server 1353A can manage more than one media server, e.g. media server array 1360. The media nodes may all be operating to carry media, content, and data cooperatively, using timesharing, and load balancing. If the communication loading on media server array 1360 drops, media node M.sub.3 can be taken offline, indicated symbolically by open switches 1365A and 1365B, leaving media nodes M.sub.1 and M.sub.2 still operating, as indicated by closed switches 1364A and 1364B. The switches do not indicate that the input and the outputs of the particular server are physically disconnected, but rather that the server is no longer running the media node application, thereby saving power and eliminating hosting use fees for unneeded servers.

(662) As illustrated, one DMZ server 1353A, working in conjunction with signaling server 1365 can control the operation of more than one media server by downloading instructions, commands, and secrets from DMZ server 1353A to any server in server array 1360, but the converse is not true. Any attempt to gain information, to write, query, or inspect the contents of DMZ server 1353A from signaling server 1365 or from media servers 1361, 1362, and 1362 is blocked by firewall 1366, meaning that the content of the DMZ server 1353A cannot be inspected or discovered through the Internet via a media node.

(663) Thus, in a dual-channel communications system the command and control of a communications network uses a different communications channel, i.e. unique routing, separate from the content of the messages. A network of signaling servers carry all of the command and control information for the network while the media servers carry the actual content of the message. Command and control packets may include seeds, keys, routing instructions, priority settings, etc. while media includes voice, text, video, emails, etc.

(664) One benefit of dual-channel communication is the data packets contain no information as to their origins or ultimate destinations. The signaling server informs each media server what to do with each incoming data packet on a need to know basis, i.e. how to identify an incoming packet by the address of the node that sent it, or alternatively by a SDNP zip code, what to do with it, and where to send it. In this way a packet never contains more routing information than that pertaining to its last hop and its next hop in the cloud. Similarly, the signaling servers carry command and control information but have no access to the content of a data packet or any communication occurring on the media channel. This partitioning of control without content, and content without routing confers a superior level of security to dual-channel SDNP-based networks.

(665) An example of dual-channel secure communication in accordance with this invention is illustrated in FIG. 103A, where command and control data packets comprising seed 929 and decryption key 1030 are communicated by signaling servers 1365 while media and content are communicated between media servers 1118. In this example, prior to any communication, zone Z1 secrets 1350A are supplied to all zone-Z1 DMZ servers including servers 1353A and 1353B, where such shared secrets may, without limitation, include seed generator 921, number generator 960, and algorithms 1340, but do not include keys such as decryption key 1030. Before communication commences, signaling node S.sub.s, hosted by sending signaling server 1365, sends a command and control packet comprising numeric seed 929 and decryption key 1030 or other security settings to destination signaling node S.sub.d. This information, combined with shared secrets and security settings contained within DMZ servers 1353A and 1353B, is then used to instruct how sending media node M.sub.S should transfer encrypted payload 1342 to receiving media node M.sub.R. The encryption of payload 1342 information is illustrated by padlock 1339.

(666) In this manner, aside from the data 1341 being communicated, the only security-related data included within payload packet 1342 is state 920, describing the time that payload packet 1342 was created. Once payload packet 1342 arrives at receiving media node M.sub.R, it is decrypted by decryption key 1030. After being decrypted, seed 929, combined with state information 920 and shared secrets 1350A supplied by DMZ server 1353B, is used to unscramble, mix and split payload packet 1342 and other incoming data packets in accordance with the previously disclosed methods. Although the data packet may carry information of the time it was last modifiedstate information especially useful for generating decryption keys locally, the concurrent use of a seed transmitted over the command and control channel enables identifying splitting and unscrambling operations performed previously on the incoming data packet but at a time not necessarily performed in the immediately previous node.

(667) In an alternate embodiment shown in FIG. 103B, numeric seed 929 is delivered a priori, i.e. before payload packet 1342, over the media channel but decryption key 1030 is still delivered over the signaling channel. As such, a combination or permutations of delivery methods is possible in order to communicate securely. As an alternative, the delivery of seeds, keys and other dynamic security settings can be varied over time.

(668) In order to facilitate the end-to-end security described previously, executable code, shared secrets, and keys also have to be installed in a client, typically downloaded as an application. To prevent revealing security settings used on the SDNP network, these downloads are defined in a separate zone known only by the client and the cloud gateway node with which it communicates. As shown in FIG. 104, to enable a mobile device such as cell phone 32 to communicate using the SDNP cloud, it must first become an authorized SDNP client. This step involves downloading zone U1 software package 1352D from SDNP administration server 1355 to client node C.sub.1,1, i.e. cell phone 32, using secure download link 1354, valid for only a limited time window. If the download takes too long to complete or fails to meet certain authentication criteria confirming that the user is a real device and not a hacker's computer pretending to be a client, the file is never decrypted or installed on the cell phone 32. Contained within zone U1 software package 1352D is executable code 1351, specific to the OS of the cell phone 32 or other device to which the code is being installed, e.g. iOS, Android, Windows, MacOS, etc., and zone U1 secrets 1350D, which may include some combination of seed generator 921, number generator 960, algorithms 1340, encryption key 1022 and decryption key 1030, all specific to client zone U1.

(669) For any zone U1 external client node C.sub.1,1 to communicate with the zone Z1 SDNP cloud 1114, gateway nodes such as media node M.sub.a,d, must receive information regarding both the zone Z1 and the zone U1 security settings, as contained within the zone U1, Z1 download package 1352E. Using time-limited, secure download methods indicated by padlock 1354, both the zone Z1 and the zone U1 secrets are downloaded via link 1350C into DMZ server 1353C, and executable code 1351 is downloaded via link 1351 and installed into SDNP media node Mai as well as into any other zone Z1 media nodes required to perform gateway connections between cloud 1114 and external clients, i.e. connections supporting last-mile connectivity. Once both media node M.sub.a,d in zone Z1 and client node C.sub.1,1 in zone U1 are both loaded with the content of download packages 1352E and 1352D respectively, then secure communication 1306 can ensue, including encryption operation 1339.

(670) Since communication from a secure cloud in zone Z1 hosted on media servers 1118 to client node C.sub.1,1 hosted on an external device such as cell phone 32 in zone U1 may likely occur over a single communication channel, some means is needed to convert the dual-channel communication employed within the cloud 1114 to single-channel communication needed over the last mile. An example of the role of the SDNP gateway node in implementing dual-channel to single-channel conversion is illustrated in FIG. 105A, where zone Z1 command and control packets entering signaling node S.sub.d in signaling server 1365 are combined with media content in gateway media node M.sub.R to create single-channel communication with payload packet 1342, comprising data 1341 along with zone U2 security settings including state 920, providing the time when the data packet 1342 was created, numeric seed 929, and encryption key 1022, to be used for encrypting the next packet, i.e. the packet to be created by node C.sub.1,1.

(671) Payload packet 1342 is encrypted using encryption operation 1339. To decrypt payload packet 1342, decryption key 1030 must be used, where the decryption key 1030 comprises one of several shared zone U1 secrets 1350D, downloaded previously into secure app and data vault 1359 along with other zone U1 secrets such as seed generator 921, number generator 960 and algorithms 1340. Alternatively, as shown in FIG. 105B, an a priori seed 929 can be delivered first and used to unscramble a scrambled decryption key 1030, which in turn is used to decrypt payload 1342. State 920 may then be used to decrypt or unscramble data 1341 providing multiple barriers to combat security breaks in last-mile communication.

(672) In order to prevent pattern recognition of algorithms used repeatedly by a client, the address or code used to select an algorithm from a list of algorithms installed on a client is, in accordance with this invention, changed at a regular schedule, for example, weekly, daily, hourly, etc. This feature, referred to as shuffling occurs in a manner analogous to shuffling the order of cards in a deck and similar to the shuffling performed within the network. Shuffling reorders the numbers used to identify any given algorithm in a table of algorithms, regardless whether such algorithm table comprises a method for scrambling, mixing, or encryption. As shown in FIG. 106, to shuffle any algorithm table in client node C.sub.1,1, e.g. hosted on cell phone 32, while insuring that the SDNP cloud is able to interpret the new algorithm addresses, signaling server 1365, hosting signaling node S.sub.s, sends numeric seed 929 to client node C.sub.1,1, which in turn feeds the seed into zone U1 number generator 960. The resulting number is used to trigger shuffling algorithm 1312, converting zone U1 algorithm table 1368A into a new zone U1 algorithm table 1368F and storing the revised table in secure apps and data register 1359, located within client node C.sub.1,1. A signaling server (not shown) creates numeric seed 929 based on state information derived from schedule time 1310 and event date 1311 used to schedule the shuffling process. The same state and date information is used to shuffle the tables in DMZ server 1353A, insuring that the cloud and client algorithm tables are identical and synchronized.

(673) An improved method to pass security settings from the cloud to client node C.sub.1,1 is to employ dual-channel communication, as shown in FIG. 107, where media node M.sub.R, hosted by media server 1118, sends numeric seed 929 to the client node C.sub.1,1, and signaling node S.sub.d, hosted by a separate signaling server 1365, sends decryption key 1030 to client node C.sub.1,1. The advantage of this method is that that the decryption key 1030 comes from a different source, with a different SDNP packet address, than the numeric seed 929 and the payload packet 1342. A possible disadvantage is that, despite the tact that the communication paths are different, it is likely in many cases that both network channels are carried by the same physical medium, for example a single WiFi or LTE connection to cell phone 32. Scrambling or encrypting decryption key 1030 before its transport from signaling server 1365 to the client node C.sub.1,1 can largely correct this deficiency, so that it cannot be intercepted or read by packet sniffing.

(674) In operation, numeric seed 929, passed via the media channel from media node M.sub.R to client node C.sub.1,1, is used to select a decryption algorithm from algorithm table 1340 and unlocking the security on decryption key 1030 shown by padlock 1339C. Once unlocked, decryption key 1030 is used to unlock the encryption performed on payload packet 1342 by encryption operation 1339B. Numeric seed 929, in conjunction with zone U1 secrets 1350D, is then used to recover data 1341 for use by client node C.sub.1,1.

(675) If an asymmetric key exchange is employed, as shown in FIG. 108, DMZ server 1353A creates a pair of asymmetric keys comprising secret decryption key 1030A, and public encryption key 1370A The decryption key 1030A remains secret in the DMZ server as a zone Z1 secret and the public encryption key 1370A is passed via signaling node S.sub.d to key exchange server 1369. The key exchange server 1369 holds the encryption key 1370A until it is needed, then passes it as needed to client device 1335. When client node C.sub.1,1 prepares a payload data packet 1342 to be sent to media node M.sub.R, it first downloads the zone Z1 encryption key 1370A from key exchange server 1369 While the signaling server can pass the encryption key to client node C.sub.1,1 directly, numerous advantages exist for using key exchange server 1369. The first benefit of using a public key exchange server is the benefit of being hidden in plain sight, i.e. safety in numbers. Since a public key server potentially issues millions of encryption keys there is no way for an interloper to know which key to ask for to hack into an unauthorized conversation. Even if by some miracle they choose the right key, the encryption key only allows them to encrypt messages, not to decrypt them. Thirdly, the distribution of public keys frees the signaling server from having to distribute keys and confirm delivery. Finally, by employing a public key exchange server, there is no way for a cyber pirate to trace where the encryption key came from, making it difficult to trace a caller through their signaling server.

(676) After obtaining the encryption key 1370A, node C.sub.1,1 on client device 1335 encrypts the payload packet 1342 using the selected encryption algorithm and encryption key 1371B. Since media node M.sub.R has access to the decryption key 1030 from DMZ server 1353A, it is able to unlock payload packet 1342 and read the file. Conversely, zone U1 secrets 1350D contain a decryption key 1030 corresponding to an encryption key (not shown) passed from client node C.sub.1,1 to key exchange server 1369. When media node M.sub.R prepares a data packet for client node C.sub.1,1, it downloads the zone U1 encryption key 1370A and then encrypts the payload packet 1342 for delivery to client node C.sub.1,1. Since cell phone 32 has access to the zone U1 secrets, including zone U1 decryption key 1030, it is able to decrypt and read payload packet 1342.

(677) In the aforementioned specified methods and other combinations thereof, secure communication including the delivery of software, shared secrets, algorithms, number generators, numeric seeds, and asymmetric or symmetric encryption keys can be realized in accordance with this invention.

(678) SDNP Packet Transport

(679) Another inventive aspect of secure communication in accordance with this invention is the inability for a cyber attacker to determine where a data packet or a command and control packet came from and to where it is destined, i.e. the true source and the final destination are disguised, revealing only the source and destination of a single hop. Moreover, within a single SDNP cloud the SDNP addresses employed are not actual IP addresses valid on the Internet but only local addresses having meaning with the SDNP cloud, in a manner analogous to a NAT address. In contrast to data transport in a NAT network, during the routing of data across the SDNP network, the SDNP addresses in the data packet header are rewritten after each node-to-node hop. Moreover, the media node does not know the routing of a data packet other than the last media node where it came from and the next media node where it will go. The protocols differ based on the previously disclosed single-channel and dual-channel communication examples, but the routing concepts are common.

(680) Single-Channel Transport

(681) One example of single-channel communication is shown in FIG. 109, where data packets are transported across a SDNP meshed network connecting tablet 33 and cell phone 32, each running SDNP-enabled application 1335. In secure communication from client node C.sub.2,1 to client node C.sub.1,1 the data traverses a single-channel last-mile routing in zone U2 from client node C.sub.2,1 to media node M.sub.a,f, followed by meshed routing in the zone Z1 SDNP cloud from gateway media node M.sub.a,f, to gateway media node M.sub.a,d, culminating in single-channel last-mile routing in zone U1 from media node M.sub.a,d to client node C.sub.1,1. Data packet 1374B illustrates the IP addressing where the packet is sent from source IP Addr TB to IP Addr MF, the IP address for media server 1220F.

(682) These last-mile addresses represent real IP addresses. Once entering the zone Z1 cloud, the source IP address in SDNP packet 1374F changes to a pseudo-IP address SDNP Addr MF, an NAT type address that has no meaning in the Internet. Assuming for simplicity's sake that network routing involves a single hop, then the destination address is also a pseudo-IP address, in this case SDNP Addr MD. Over the last mile in zone U1, the addresses shown in SDNP packet 1374G revert to real IP addresses, with a source address of IP Addr MD and a destination IP Addr CP. In real-time packet transport, all of the SDNP media packets use UDP, not TCP. As described previously, the payload varies by zonein last-mile zone U2, the payload of SDNP media packet 1374B comprises a U2 SDNP packet, in meshed network and SDNP cloud zone Z1 the payload of SDNP media packet 1374F comprises a Z1 SDNP packet, and in last-mile zone U1 the payload of SDNP media packet 1374G comprises a U1 SDNP packet. So unlike in Internet communication, a SDNP media packet is an evolving payload, changing in address, format and content and it traverses the communication network.

(683) FIGS. 110A-110F contain a series of flow charts illustrating how a single-channel SDNP communication takes place. In single-channel ad hoc communication, the communicating parties exchange information over a single channel, the media channel, in a sequence to create a session and then to transfer data or voice. As shown in step 1380A of FIG. 110A, the client opens the SDNP-enabled application 1335 and commences a dialog with any SDNP default media server listed on default SDNP server table 1375. Any one of the default SDNP servers, in this case media server 1120S, hosting media node M.sub.a,s, is used as a first contact number whenever an authorized client wishes to initiate a call or establish a session using the SDNP network. In single-channel communication, server 1220S performs two functionsacting as a default server for first contact from new callers, and concurrently performing the function of a media server for carrying calls already initiated. In an alternative embodiment, a separate dedicated name server is used to operate as first contact, not at the time a call is initiated but whenever the devices first connects, i.e. registers, on the network. The use of a name server in accordance with this invention is disclosed later in this application.

(684) The client's SDNP-enabled application 1335 can be an SDNP-enabled secure application like a personal private messenger or secure email running on a cell phone, tablet or notebook. Alternatively, the client may comprise secure hardware devices running embedded SDNP software. SDNP-embedded devices may include an automotive telematics terminal; a POS terminal for credit card transactions; a dedicated SDNP-enabled IoT client, or a SDNP router. A SDNP router disclosed herein is a general purpose hardware peripheral used to connect any device not running the SDNP software to the secure SDNP cloud, e.g. any notebook, tablet, e-reader, cell phone, game, gadget with Ethernet, WiFi or Bluetooth connectivity.

(685) After client application 1335 contacts one of the default SDNP servers, it is next redirected to a SDNP gateway node. The gateway node may be selected by its physical proximity between the client's location and the server, by the lowest network traffic, or as the path with the shortest propagation delay and minimum latency. In step 1380B, the default SDNP server 1220S redirects the client's connection to the best choice SDNP gateway media server 1220F, hosting SDNP gateway media node M.sub.a,f. Gateway media node M.sub.a,f, then authenticates both parties' certificate 1357, confirms the user, establishes whether the call is free or a premium feature and, as applicable, confirms an account's payment status, and thereafter commences a SDNP session.

(686) In step 1380C, the client application 1335 sends an initial SDNP packet 1374A requesting address and routing information for the call destination, i.e. the person or device to be called, using route query 1371, directed to gateway media server 1220F. Since the SDNP packet 1374A, which includes route query 1371, represents a command and control packet rather than real-time communication (i.e., data packet), it is delivered using TCP rather than UDP. The route query 1371 may specify that the contact information be provided to client application 1335 in any number of formats, including the phone number, SDNP address, IP address, URL, or a SDNP specific code, e.g. a SDNP zip code of the destination device, in this case cell phone 32. Route query 1371 is therefore a request for information about the party being called, i.e. for any necessary information to place the call, comprising for example either the SDNP zip code, their IP address, or their SDNP address.

(687) In step 1380D of FIG. 110B the SDNP gateway media node M.sub.a,f searches the SDNP cloud 1114, acquires the destination address, meaning that media node M.sub.a,f identifies the party being called and obtains any necessary information to place the call, comprising for example either the SDNP zip code, the IP address, or the SDNP address of the person being called, and then in step 1380E, SDNP gateway media node M.sub.a,f supplies the routing information, the path which the call will take, and the encryption keys needed to traverse the specific zone to client application 1335 Once the client, tablet 33, obtains the destination address, in step 1380F, tablet 33, initiates a call with SDNP data packet 1374B. Voice sound waves 1384A, captured by microphone 1383A, are converted into digital information by an audio CODEC (not shown) and fed into application 1335. Combining the audio data with address routing and other information assembled into to a SDNP header, application 1335 constructs SDNP data packet 1374B for first-mile routing from IP Addr TB to IP Addr MF and commences packet transport to media node M.sub.a,f. SDNP header, embedded into the payload 1372 of data packet 1374B, may include urgency, delivery preferences, security protocols, and data-type specifications. Since the first-mile routing of SDNP data packet 1374B occurs using an IP address, packet transport is similar to conventional Internet traffic, except that the actual data content is scrambled and encrypted using SDNP zone U2 security settings, and the SDNP header contained in the U2 SDNP payload 1372 encapsulating the data is also formatted specifically in accordance with the secure dynamic network protocol for zone U2. The secure dynamic network protocol for zone U2 is the set of shared secrets specifically applicable for communication traversing that specific zone, e.g. a zone U2 seed calculated using a zone U2 specific seed generator, i.e. a seed generation method using an algorithm, as described previously in the example of FIG. 51A, but using security settings, tables, etc. specific to Zone U2. Similarly, the zone U2 encryption and scrambling algorithms are based on the security settings specific to Zone U2. As such, packets transmitted by tablet 33 are scrambled and encrypted in the manner described above based on a state (time) and that these packets contain decryption keys and seeds that identifies the state (time) they were created enabling the packets to unscrambled and decrypted by media node M.sub.a,f using the security settings specific for zone U2.

(688) To summarize, each node identifies each packet it receives by its tag. Once the node has identified the packet, it performs whatever decryption, unscrambling, mixing, scrambling, encryption and splitting operations on the packet that the signaling server has instructed it to perform, in the order specified. The algorithms or other methods used in these operations may be based on a state, e.g., the time when the packet was created, or a seed generated in accordance with an algorithm that is determined by a state. In performing each operation, the node may use the state or seed to select a particular algorithm or method from a table in its memory. Again as instructed by signaling server, the node gives each packet a tag and then routes the packet on to the next node in its journey across the SDNP network. It is understood, of course, that where the incoming packets have been mixed and/or split, the packets transmitted by a node will not normally be the same as the packets it receives, as some data segments may have been transferred to other packets, and data segments from other packets may have been added. Thus, once a packet has been split, each resulting packet gets its own tag and travels on its own route completely ignorant of how its siblings will make it to the same ultimate destination. The node is ignorant of the route of each packet except for the next hop.

(689) In single-channel SDNP systems, the gateway and other media nodes have to perform triple duty, emulating the jobs of the name server and the signaling server. In fact, single-channel, dual-channel and tri-channel systems differ in that the three functionspacket transmission, signaling and nameare performed in the same servers in a single-channel system, in two types of servers in a dual-channel system, and the three types of servers in a tri-channel system. The functions themselves are identical in all three types of systems.

(690) In a distributed system, the servers that perform the signaling function know the ultimate destination of the packets, but no single server knows the entire route of the packets. For example, the initial signaling server may know a portion of the route, but when the packets reach a certain media node the signaling function is handed off to another signaling server, which takes over the determination of the route from that point on.

(691) To take a rough analogy, if a packet is to be sent from a cell phone in New York City to a laptop in San Francisco, the first signaling server (or the first server performing the signaling function) might route the packet from the cell phone to a local server in New York (the entry gateway node) and from there to servers in Philadelphia, Cleveland, Indianapolis and Chicago, a second signaling server might route the packet from the Chicago server to servers in Kansas City and Denver, and a third signaling server might route the packet from the Denver server to servers in Salt Lake City, Reno and San Francisco (the exit gateway node) and finally to the laptop, with each signaling server determining the portion of the route that it is responsible for based on the propagation delays and other current traffic conditions in the SDNP network. The first signaling server would instruct the second signaling server to expect the packet in the Chicago server, and the second signaling server would instruct the third signaling server to expect the packet in the Denver server, but no single signaling server (or no server performing the signaling function) would know the full route of the packet.

(692) Of course, as indicated above, the packet may be mixed and split along its route. For example, instead of simply routing the packet from the Philadelphia server to the Cleveland server, the signaling server could instruct the Philadelphia server to split the packet into three packets and route them to servers in Cincinnati, Detroit and Cleveland, respectively. The signaling server would then also instruct the Philadelphia server to give each of the three packets a designated tag and it would inform the servers in Cincinnati, Detroit and Cleveland of the tags so that they could recognize the packets

(693) Step 1380G of FIG. 110C illustrates SDNP data packet 1374C being routed from gateway media node M.sub.a,f, hosted by media server 1220F, to SDNP media node M.sub.a,j, hosted by media server 1220J. In single-channel communication, the routing of the data is first determined at the time that the gateway first obtained the address being called in step in 1380D. Unlike the first-mile routing of IP data packet 1374B, this first intra-cloud hop of SDNP packet 1374C occurs using SDNP addresses SDNP Addr MF and SDNP Addr MJ, not recognizable on Internet. In single-channel communication, the routing of the data, i.e., the sequence of nodes through which each packet will pass on its route to its destination, is determined at the time that the gateway node (here node M.sub.a,f) first obtains the address being called (here in step 1380D.

(694) Payload 1373A of SDNP data packet 1374C is scrambled and encrypted, using SDNP zone Z1 security settings, and the SDNP header contained in the SDNP data packet 1374C encapsulating the data within payload 1373A is also formatted specifically in accordance with the secure dynamic network protocol for zone Z1. The secure dynamic network protocol for any zone is the set of shared secrets specifically applicable for communication traversing that specific zone, in this case a zone Z1 seed calculated using a zone Z1 seed algorithm, a zone Z1 encryption algorithm and so on. For security purposes, zone Z1 security settings are not communicated to zone U2, and vice versa.

(695) Step 1380H illustrates SDNP data packet 1374D being routed from media node M.sub.a,d hosted by media server 1220J, to SDNP media node M.sub.a,d hosted by media server 1220S The cloud hop of SDNP packet 1374D also occurs using SDNP addresses SDNP Addr MJ and SDNP Addr MS, not recognizable on the Internet. Payload 1373B of SDNP data packet 1374D is scrambled and encrypted, using SDNP zone Z1 security settings, and the SDNP header contained in the SDNP data packet 1374D encapsulating the data within payload 1373B is also formatted specifically in accordance with the secure dynamic network protocol for zone Z1.

(696) This process of sending a packet between nodes in the SDNP cloud may occur once or may be repeated multiple times, each repetition involving re-packeting and re-routing operation 1373.

(697) The final cloud-hop of SDNP packet 1374E, shown in step 1380J of FIG. 110D, likewise occurs using SDNP addresses SDNP Addr MS and SDNP Addr MD, not recognizable on Internet. SDNP data packet 1374E is routed from media node M.sub.a,s, hosted by media server 1220S, to SDNP gateway media node M.sub.a,d, hosted by media server 1220D. Payload 1373C within SDNP data packet 1374E is scrambled and encrypted using zone Z1 SDNP security settings, and the SDNP header contained in the SDNP data packet 1374E encapsulating the data within payload 1373C is also formatted specifically in accordance with the secure dynamic network protocol for zone Z1.

(698) In step 1380K, data packet 1374G is routed out of the secure cloud from gateway media node M.sub.a,d, hosted by media server 1220D, to client node C.sub.1,1, hosted by application 1335 on cell phone 32. This last-mile routing of IP packet 1374G occurs using IP addresses IP Addr MD and IP Addr CP, recognizable on the Internet, except that payload 1374 within IP packet 1374G is scrambled and encrypted using SDNP zone U1 security settings, and the SDNP header contained in the SDNP data packet 1374G encapsulating the data within payload 1374 is also formatted specifically in accordance with the secure dynamic network protocol for zone U1. Upon delivering the data contents of payload 1374 to application 1335 in cell phone 32, speaker 1388B converts the digital code into sound 1384A using an audio CODEC (not shown).

(699) In step 1380L, shown in FIG. 110E, the called person responds with voice directed in the opposite direction from the original communication. As such, voice sound waves 1384B are captured by microphone 1383B and converted into digital code by an audio CODEC (not shown) implemented within application 1335 in cell phone 32. Using zone U1 SDNP security settings, the voice data is combined with a zone U1 SDNP header to create payload 1375, and directed from IP Addr CP to IP Addr MD, using IP data packet 1374H. This first-mile routing of IP packet 1374H occurs using IP addresses recognizable on the Internet, except that payload 1375 within data packet 1374H is scrambled and encrypted using zone U1 SDNP security settings, and the SDNP header contained in the SDNP packet 1374H encapsulating the data within payload 1375 is also formatted specifically in accordance with the secure dynamic network protocol for zone U1.

(700) As shown in step 1380M, upon receiving the IP packet 1374H, gateway media node M.sub.a,d, hosted by server 1220D, converts the addressing to SDNP routing and sends SDNP data packet 1374J and its payload 1376A to media node M.sub.a,j, hosted by computer server 1220U, using zone Z1 security settings. This SDNP node-to-node communication may comprise a single node-to-node hop or involve transport through a number of media nodes, with each hop involving re-packeting and re-routing operation 1373.

(701) In step 1380N of FIG. 110F, SDNP data packet 1374K and its zone Z1 specific payload 1376B is directed from media node M.sub.a,j, hosted by computer server 1220J, to gateway media node M.sub.a,f, hosted by computer server 1220F. The SDNP addresses SDNP Addr MJ and SDNP Addr MF used within SDNP packet 1374K are SDNP-specific addresses similar to NAT addresses and do not represent valid Internet routing. In step 1380P, gateway media node M.sub.a,f converts the contents of the incoming data packet from a zone Z1 specific payload 1376B into a zone U2 payload 1377 and using IP addresses IP Addr MF and IP Addr TB directs IP packet 1374L to client node C.sub.2,1 hosted by tablet 33, as shown in FIG. 109. Application 1335 then extracts the payload 1377 data and after decryption and unscrambling converts the digital code using an audio CODEC (not shown) into sound waves 1384B produced by speaker 1388A.

(702) The entire ad hoc communication sequence to initiate the call and to route voice from the caller, i.e. tablet 33, to the person called, i.e. cell phone 32, is summarized in FIG. 111A. As shown, IP command and control packet 1374A is used to obtain contact information to determine routing, and IP data packet 1374B is used to initiate first-mile routing, using IP addresses to reach the SDNP gateway node M.sub.a,f at an IP address of IP Addr MF. All first-mile communication between tablet 33 and the SDNP cloud 1114 uses zone U2 security settings.

(703) The gateway media node M.sub.a,f then converts the routing to SDNP-specific routing addresses and uses SDNP packets 1374C, 1374D, and 1374E to move the communication through the SDNP cloud 1114 from SDNP Addr MF to SDNP Addr MJ to SDNP Addr MS to SDNP Addr MD respectively, all using zone Z1 security settings. This sequence is functionally equivalent to SDNP data packet 1374F directing the communication packet from SDNP Addr MF directly to SDNP Addr MD. Because there is no routing supervisor in ad hoc communication to oversee packet delivery, the command and control of packet routing within the SDNP cloud 1114 can be accomplished in one of two ways. In one embodiment, the source and destination addresses of each of SDNP data packets 1374C, 1374D, and 1374E explicitly and rigorously define the hop-by-hop path of the packet through the SDNP network, the path being chosen in single-channel communication by the gateway media node in advance for the best overall propagation delay during transport. In an alternative embodiment, a single gateway-to-gateway packet, e.g. SDNP data packet 1374F, is used to define the SDNP nodal gateways into and out of the SDNP cloud, but not to specify the precise routing. In this embodiment, each time a packet arrives in a SDNP media node, the media node prescribes its next hop much in the same way as routing over the Internet occurs, except that the SDNP media node will automatically select the shortest propagation delay path, whereas the Internet does not.

(704) Finally, when packet 1374E reaches the gateway media node Md at SDNP Addr MD, the gateway media node M.sub.a,d creates IP data packet 1374G, converting the incoming data packet into IP addresses IP Addr MD and IP Addr CP and changes the security settings to those of zone U1.

(705) Another summary of this routing is shown in FIG. 111B, comprising three intra-cloud hops 1441C, 1441D and 1441E, and two last-mile routings 1441B and 1441F. The packet addresses shown below the cloud map reveal a mix of two forms of packet addresses during transportIP address routing and SDNP address routing, analogous to the use of NAT addresses. Specifically, packet addresses 1442A and 1442F represent Internet IP addresses while packet addresses 1442C and 1442D represent SDNP IP addresses. Packet addresses 1442B and 1442E, used by the gateway media nodes, contain both IP and SDNP addresses, meaning SDNP gateway nodes are responsible for address translation as well as for converting zone U2 security settings into zone Z1 security settings and for converting zone Z1 settings into zone U1 security settings.

(706) In a similar manner, FIG. 112A summarizes the reply portion of the communication, comprising first-mile zone U1 data packet 1374J, using IP addresses IP Addr CP and SDNP Addr MD; SDNP cloud routing using SDNP addresses SDNP Addr MD, SDNP Addr MD, and SDNP Addr MF in zone Z1 specific data packets 1374K and 1374L; and last-mile zone U2 data packet 1374J, using IP addresses IP Addr CP and SDNP Addr MD. The corresponding cloud routing map is shown in FIG. 1128, where first-mile hop 1441H and last-mile hop 1441L use IP only addresses 1442G and 1442L, intra-cloud hops 1441J and 1441K use only SDNP addresses, and gateway media nodes M.sub.a,d and M.sub.a,f perform translation between IP and SDNP addresses 1442H and 1442K.

(707) FIG. 113A is a schematic diagram illustrating how an SDNP packet is prepared. During a voice or video communication, sound, voice or video signal 1384A is converted into analog electrical signals by microphone 1383A and then digitized by audio video CODEC 1385. The resulting digital data string 1387 comprising a sequence of data segments represented in sequence alphabetically (9A, 9B, etc.), is then subjected to parse operation 1386 to make smaller data packet 1388 comprising audio or video content, then junk 1389 is inserted by single-channel splitting operation 1106. Single-channel splitting operation 1106 involves parsing 1386 long packet 1387 into smaller packet 1388 and inserting junk data 1389, resulting in extended data packet 1390 comprising two sectionsone with header Hdr 9, the other with junk header J. The string of data segments contained between Hdr 9 and Hdr J contain the audio or video data in packet 1388 with some trailing junk data segments. The data segments following Hdr J contain no useful data. SSE operation 1213 then scrambles the data from former packet 1388 to create data string 1391, adds SDNP preamble 1399A to create SDNP packet 1392, and then encrypts the entire packet, except for the SDNP preamble, to create scrambled, encrypted payload 1393A, which in turn is loaded into SDNP packet 1374B with source address IP Addr TB and destination address IP Addr MF, ready for routing. The headers Hdr 9 and Hdr J allow each component piece to be identified within the payload. The function and the format of the headers and the SDNP preamble are discussed later in the application.

(708) In a similar manner, the data segments 9G et seq. in data string 1387 are formed into additional SDNP packets.

(709) FIG. 113B illustrates various other methods can be used in the creation of a payload from its original serial data. For example, the data string 1387 from CODEC 1385 can be parsed and split in a different manner. As shown, data segments 9A, 9B, 9D, and 9F are assembled into the Hdr 91 section with missing data segments replaced by junk data, while data segments 9C and 9E are assembled into the Hdr 92 section, together creating data packet 1394. Next, the data segments in each header's section are scrambled so that the individual data segments in data field 1399C following Hdr 91 are not mixed with the data segments in data field 1399E following Hdr 92. The resulting SDNP packet 1395 comprises SDNP preamble 1399A, a first header 1399B labeled Hdr 91, a first data field 1399C, a second data header 1399D (Hdr 92) and a second data field 1399E. Other methods may be employed to spread the data segments 9A-9F of data string 1387 across the various data fields. The one shown is for illustrative purposes only.

(710) SDNP packet 1395, containing multiple data fields separated by multiple headers, may then be encrypted in one of several ways. In full-packet encryption, all of the data in SDNP packet 1395 is encrypted, except for the data in SDNP preamble 1399A, i.e. all the content of first header 1399B, first data field 1399C, second data header 1399D and second data field 1399E are all encrypted to form SDNP packet 1396 comprising unencrypted SDNP preamble 1399A and ciphertext 1393A. Alternatively, in message encryption, SDNP packet 1397 comprises two separately encrypted ciphertext stringsciphertext string 1393B, comprising the encryption of data header 1399B and data field 1399C, and ciphertext string 1393C, comprising the encryption of data header 1399D and data field 1399E. In another embodiment of this invention, referred to as data-only encryption, only data-fields 1399C and 1399E are encrypted into ciphertext strings 1393D and 1393E, but data headers 1399B and 1399D are left undisturbed. The resulting SDNP packet 1398 comprises plaintext for SDNP preamble 1399A, first data header 1399B, and second data header 1399D and ciphertext strings 1393D and 1393E, representing independently encrypted versions of data fields 1399C and 1399E respectively

(711) In single-channel communication, to relay required routing and priority information to the next media node, SDNP payload 1400, shown in FIG. 114, must carry the requisite information. This data is contained either in the SDNP preamble 1401 or in the data field header 1402. SDNP preamble 1401 comprises information relevant to the entire packet, including a description of the number of data fields Fld # with up to eight possible fields, the length of each data field L Fld X, where in this embodiment, X may vary from 1 to 8 fields, the SDNP zone where the SDNP packet was created, e.g. zone Z1, two numeric seeds, and two keys generated through the shared secrets.

(712) Data field header 1402 follows a fixed format for each one of the X data fields. Data field header 1402 includes an address type for the destination and the destination address of the specific data field, i.e. the destination of this specific hop in the cloud. The destination address of every data field in a given packet is always the same because the packet remains intact until it arrives at the next media node. When a packet is split into multiple packets, however, the field destination addresses in each of the split packets is different from the field destination addresses in each of the other split packets if the packets are going to different media nodes.

(713) In multi-route and meshed transport, the field destination address is used for splitting and mixing the various fields used in dynamic routing.

(714) The address type of the next hop can change as the packet traverses the network. For example it may comprise an IP address between the client and the gateway, and an SDNP address or a SDNP zip once it enters the SDNP cloud. The destination may comprise an SDNP specific routing code, i.e. SDNP address, SDNP Zip, or an IPv4 or IPv6 address, a NAT address, a POTS phone number, etc.).

(715) The packet field labeled Field Zone describes the zone where a specific field was created, i.e. whether a past encryption or scrambling was performed with U1, Z1, U2, etc. zone settings. In some instances, unscrambling or decrypting a data packet requires additional information, e.g. a key, seed, time or state, in which case the packet field labeled Field Other may be used to carry the field-specific information. The packet field labeled Data Type, if used, facilitates context-specific routing, distinguishing data, pre-recorded video, text and computer files not requiring real time communication from data packets containing time sensitive information such as voice and live video, i.e. to distinguish real-time routing from non-real-time data. Data types include voice, text, real-time video, data, software, etc.

(716) The packet fields labeled Urgency and Delivery are used together to determine best how to route the data in a specific data field. Urgency includes snail, normal, priority, and urgent categories. Delivery includes various QoS markers for normal, redundant, special, and VIP categories. In one embodiment of this invention, the binary size of the various data fields as shown in table 1403 is chosen to minimize the required communication bandwidth. For example, data packets as shown may range from 0 to 200 B whereby eight packets of 200 B per data field means that a SDNP packet can carry 1,600 B of data.

(717) Dual-Channel Communication

(718) In one embodiment of dual-channel SDNP data transport, shown in FIG. 115, content travels through media channels from client node C.sub.2,1, hosted on tablet 33, to gateway media node M.sub.a,f over zone U2 first-mile routing, then across zone Z1 meshed routing, hosted on computer servers 1118, and finally from gateway media node Mat over zone U1 last-mile routing to client C.sub.1,1 hosted on cell phone 32. Routing is controlled by first-mile IP packet 1374B, SDNP packet 1374F over the SDNP meshed network, and last-mile IP packet 1374G.

(719) In parallel, to the media and content transport, client C.sub.2,1, communicating with signaling node S.sub.s, hosted by signaling server 1365, sends numeric seed 929 and decryption key 1030 to client C.sub.1,1 through signaling server S.sub.d, seed 929 and decryption key 1030 being based on the time or state when client C.sub.2,1 sent them. By exchanging security settings such as keys and seeds (also known as security credentials) directly between the clients over signaling route 1405, and not through zone Z1, end-to-end security is realized beneficially eliminating any risk of a network operator in zone Z1 gaining access to security settings and compromising the security of Zone U1 or Zone U2. This embodiment represents yet another dimension of security in SDNP network communication. Seed 929, for example, may be used to scramble and unscramble the data packets in the client's applications. Similarly, as shown, decryption key 1030 allows only client C.sub.1,1 to open the encrypted message. Since key 1030 and numeric seed 929 never pass through zone Z1, a network operator cannot compromise the network's security. When the data packets enter the gateway node M.sub.a,f from client C.sub.2,1, the incoming data packets are already encrypted and scrambled. The packets received by client C.sub.1,1 from gateway node M.sub.a,d are in the same scrambled and/or encrypted form as those leaving client C.sub.2,1 and destined for gateway node M.sub.a,f. The network's dynamic scrambling and encryption present in every node (but not explicitly shown in FIG. 115) represent a second layer of security facilitated by the SDNP cloud. In other words, this outer end-to-end security layer comprising the exchange of security credential directly between clients is in addition to the SDNP-cloud's own dynamic scrambling and encrypting.

(720) Thus, as shown in FIG. 115, the signaling nodes S.sub.s and S.sub.d instruct the media nodes M.sub.a,f and M.sub.a,d to route the data from IP Addr TB to IP Addr MF in zone U2 using IP packet 1374B, from SDNP Addr MF to SDNP Addr MD in zone Z1 using SDNP packet 1374F, and from IP Addr MD to IP Addr CP in zone U1 using IP packet 1374G. In this embodiment, since signaling nodes S.sub.s and S.sub.d only communicate directly with client nodes C.sub.2,1 and C.sub.1,1 and indirectly through the data packets on the media communication channel with gateway media nodes M.sub.a,f and M.sub.a,d, the only routing instruction to the meshed network is from gateway to gateway, using SDNP packet 1374F. The signaling servers S.sub.s and S.sub.d are unable to communicate to intermediate media nodes within the meshed network. So, in the embodiment shown in FIG. 115, the media nodes manage dynamic security within the cloud as a single-channel communication system while the signaling nodes are used to facilitate end-to-end security beyond the SDNP cloud, i.e. beyond Zone Z1.

(721) In another embodiment of dual-channel SDNP data transport, shown in FIG. 116, the signaling nodes S.sub.s and S.sub.d, hosted by servers 1365, facilitate end-to-end security for the clients and concurrently manage dynamic routing and security within the SDNP cloud. As such the signalizing nodes S.sub.s and S.sub.d not only transmit numeric seed 929 and decryption key 1030 between client nodes C.sub.2,1 and C.sub.1,1 end-to-end, using signal route 1405, but they also pass zone-specific seed 929 and decryption key 1030 as well as node-by-node single hop routing instructions, using dynamic SDNP packet 1374Z, carried by signal route 1406, to every single media node in the meshed network through which the communication packets and content move. In this manner, the signaling nodes S.sub.s and S.sub.d control routing and security, and the media nodes within the network carry content and implement the instructions from the signaling nodes S.sub.s and S.sub.d. In such an implementation, either the media nodes or the signaling nodes S.sub.s and S.sub.d carry the responsibility of tracking which media servers are online and which ones are not, and what their dynamic IP addresses are at the time.

(722) Tri-Channel Communication

(723) Greater security and enhanced network performance can be achieved by separating the responsibility of tracking the nodes in the network from the actual data transport. In this approach, a redundant network of servers, referred to as name servers, constantly monitors the network and its media nodes, freeing the signaling servers to do the job of routing and security data exchange, and enabling the media servers to concentrate on executing routing instructions received from the signaling nodes. This yields what is referred to herein as a tri-channel system and is illustrated in FIG. 117 where name server 1408, hosting name server node NS, maintains a list of active SDNP nodes in the network, comprising network node list 1410 Upon request from signaling node S, hosted by signaling server 1365, name server node NS, hosted by name server 1408, passes the network description, whereby signaling node S tracks and records the condition and propagation delay between all the media nodes in the SDNP cloud 1114, as shown in network condition table 1409, including zones U2, Z1, U1 and others. In the process of making a call, signaling node S supplies routing instructions to every node involved in the planned transport of a data packet through the network, including instructions for zone U2 first-mile routing to client node C.sub.2,1 hosted by tablet 33, instructions for zone U1 last-mile routing to client node C.sub.1,1, hosted by cell phone 32, and instructions for zone Z1 routing for all the intermediate media nodes in secure SDNP cloud 1114 used to transport the media content in SDNP data packets.

(724) To maintain an updated network description, each time a device logs on to the network, the data regarding its status and its IP address, its SDNP address, or in some cases both, is transferred to name server 1408, as shown in FIG. 118. The network status and/or address data is then stored in network address table 1415, which is stored in application 1335 running in tablet 33 or cell phone 32, application 1411 running on notebook 35 or on a desktop (not shown), embedded applications 1412 and 1413 running on automobile 1255 or in IoT device 34, represented graphically by a refrigerator. Network address table 1415 also tracks the status of all media servers in the cloud including, for example media node M.sub.a,f, hosted by computer 1220F, and media node M.sub.a,d, hosted by computer 1220D. Network address table 1415 records the routing address for any network-connected device. In nearly every case the IP address or SDNP address of a connected device is recorded and tracked in the network address table 1415. In other cases, such as media servers and optionally personal mobile devices running SDNP-enabled communication applications, network address table 1415 may record both an IP address and a SDNP address, needed for address translation in gateway media nodes.

(725) While name server node NS maintains an exhaustive description of the network, signaling node S, hosted by signaling server 1365, shown in FIG. 119, maintains a table of propagation delays 1416 between every combination of media nodes in the network available. Propagation delays table 1416 is updated by delay calculations derived from the normal movement of data packets through the network's media nodes, illustrated symbolically by stopwatches 1415A, 1415B, and 1415C, monitoring the propagation delays between media servers 1220D and 1220F, 1220F and 1220H, and 1220D and 1220H, respectively. In the event that ongoing traffic is scarce or infrequent, the SDNP network also utilizes test packets to check the health of a connection. One test packet method is illustrated in FIG. 120, where a media server is instructed by the signaling server to send out a series of packet bursts, where the data packets sent increase in size or in frequency while the delay is tracked. The resulting loading graph shown by curve 1417 reveals that the maximum loading of the specific communication route or link should be limited in size or rate not to exceed maximum loading, shown as line 1418.

(726) Given that the aforementioned information regarding the network, its node addresses, and its propagation delays is readily available in the name servers and the signaling servers, high QoS communication can best be achieved using tri-channel communication as depicted in FIG. 121. As shown, signaling node S, hosted by signaling server 1365, entirely controls the routing of data through media servers 1118 and to clients 1335 by distributing SDNP packets 1420 comprising node-to-node routing data 1374Z and zone-specific numeric seeds 929 and decryption keys 1030. In establishing a call, the client node C.sub.2,1, in this case SDNP application 1335 in tablet 33, contacts name server node NS on name server 1406, to register itself on the network and to find its nearest signaling server, whereby it contacts signaling node S on signaling server 1365 to initiate a call. Thereafter, the signaling node S manages the routing, and the media servers route the data accordingly, changing security settings for each of zones U2, Z1 and U1.

(727) Because of the importance of the name server in maintaining an up-to-date network node list 1410, shown in FIG. 122, name server node NS, hosted on name server 1408, works in concert with one or more redundant servers, illustrated by backup name server node NS2, running on backup name server 1421. In the event that any client nodes or media nodes cannot reach name server 1408, the information query automatically and seamlessly transfers to the backup name server 1421. The same redundancy method is utilized for signaling servers to insure constant availability for placing a call or for packet routing. As shown in FIG. 123, signaling node S, hosted on signaling server 1365, has a backup signaling node S2, hosted on backup signaling server 1422, which automatically takes over in the event that signaling server 1365 fails or is attacked.

(728) Communication using tri-channel SDNP packet routing in accordance with this invention is illustrated in FIG. 124A, where in step 1430A the device or caller logs into the network. To do this, the client's application 1335 on tablet 33 automatically contacts and registers itself with name server node NS, hosted on name server 1408. This event is associated with a client logging into the network, not necessarily placing a call. In the registration process name server node NS passes a list of name servers, i.e. SDNP name servers list 1431, and optionally a list of signaling servers, to the client's application 1335. With that information the device is ready and able to place a SDNP call.

(729) In the first step 1430B in actually placing the call, the tablet 33 sends IP packet 1450A to the name server node NS, requesting routing and contact information for the destination or person to be called. The contact information request, i.e. route query 1431, may come in the form of an IP address, SDNP address, phone number, URL, or other communication identifier. In step 1480C, name server node NS, hosted by name server 1408, supplies the client's SDNP application 1335 with the intended recipient's address. The reply is delivered by IP packet 1450B, using the TCP transport layer. In an alternate embodiment, the client requests the routing information from a signaling server and the signaling server requests the information from the name server.

(730) In step 1430D, shown in FIG. 124B, the client is finally able to initiate the call with IP packet 1450C from IP Addr TB to IP Addr S, the IP address of signaling server 1365, hosting signaling node S. Since IP packet 1450C is carrying the recipient's address, not real-time data, IP packet 1450C preferably employs TCP as a transport layer. Using its knowledge of the network's node-to-node propagation delays shown in table 1416, signaling node S develops a network routing plan for the SDNP network 1114 as well as last-mile connection to the SDNP gateway servers and in step 1430E communicates this routing information to SDNP cloud 1114. The signaling server sends a command and control data packet to each of the media servers to instruct them how to handle incoming data packets. The command and control data packet looks like an ordinary data packet, except that rather than carrying audio content, its payload comprises a series of instructions informing the media node how to route a packet with a specific identifying tag, SDNP address, or SDNP zip code to a new destination. Alternatively, as described above, in distributive embodiments no single signaling server develops the entire routing plan but rather a series of signaling servers develop successive parts of the routing plan as the packet proceeds through the SDNP network.

(731) Then, in step 1430F, the signaling node S sends to application 1335 in tablet 33 the gateway media node address, the zone U2 decryption keys 1030, the seeds 929 and other security settings needed for securing the first packet to be sent across the first mile.

(732) Once tablet 33 obtains the zone U2 security settings in step 1430F, it initiates a call with SDNP packet 1450D, as shown in FIG. 124C. Sound represented voice waves 1384A, captured by microphone 1383A, are converted into digital information by an audio CODEC (not shown) and fed into application 1335 in tablet 33. Combining the audio data with the address routing and other information assembled into to an SDNP header, application 1335 constructs SDNP packet 1450D for first-mile routing from IP Addr TB to IP Add MF and commences packet transport to the gateway media node M.sub.a,f. The SDNP header, embedded into the data packet's payload 1432 may include urgency, delivery preferences, security protocols, and data type specifications. The SDNP header also includes the SDNP preamble plus the MAC address, the source and destination IP addresses and the protocol field, basically the layer 2, 3 and 4 information with a payload that encapsulates the SDNP header, and all the data packets with their own SDNP sub-headers. Since the first-mile routing of SDNP packet 1450D occurs using IP addresses, packet transport is similar to conventional Internet traffic, except that the actual data content is scrambled and encrypted using the security settings for zone U2, and the SDNP header contained in the SDNP payload 1432, which also contains the data, is formatted specifically in accordance with the secure dynamic network protocol for zone U2.

(733) Step 1430H, also shown in FIG. 124C, illustrates SDNP data packet 1450E being routed from gateway media node M.sub.a,f, hosted by media server 1220F to media node M.sub.a,j, hosted by media server 1220J in the SDNP cloud. Unlike the first-mile routing of IP data packet 1450D, this first intra-cloud hop of SDNP packet 1450D occurs using SDNP addresses SDNP Addr MF and SDNP Addr MJ, not recognizable on the Internet. Moreover, payload 1433 is scrambled and encrypted using SDNP zone Z1 security settings, and the SDNP header contained in the Z1 SDNP packet encapsulating the data is also formatted specifically in accordance with the shared secrets for zone Z1. For security purposes, zone Z1 security settings are not communicated to zone U2, and vice versa.

(734) In step 1430J, shown in FIG. 124D, data packet 1450F is routed out of the secure SDNP cloud from gateway media node M.sub.a,d, hosted by media server 1220D, to client node C.sub.1,1, hosted by application 1335 on cell phone 32. This last-mile routing of IP packet 1450F occurs using IP addresses IP Addr MD and IP Addr CP, recognizable on the Internet, but payload 1434 is scrambled and encrypted using SDNP zone U1 shared secrets, and the SDNP header contained in the payload 1434 is also formatted specifically in accordance with the shared secrets. Upon delivering the data contents of payload 1434 to application 1335 in cell phone 32, speaker 1388B converts the digital code into sound waves 1384A using an audio CODEC (not shown).

(735) When the incoming SDNP packet 1450F is received by application 1335 in cell phone 32, it can only see from the address the last media node M.sub.a,d where the data packet left the SDNP cloud. Unless the SDNP payload carries information regarding the caller, or unless the signaling node S supplies this information, there is no way for the person called or receiving the data to trace its origins or its source. This feature, anonymous communication and untraceable data delivery is a unique aspect of SDNP communication and an intrinsic artifact of the single-hop dynamic routing in accordance with this invention. The SDNP network delivers information about the caller or source only if the caller so desires it, otherwise there is no information availableanonymity is the default condition for SDNP packet delivery. In fact, the sending client's SDNP application has to intentionally send a message informing a person being called or messaged that the information came from the specific caller. Since the signaling server knows the caller and the packet's routing it can determine a route for a reply data packet without ever revealing the caller's identity.

(736) Alternatively the signaling server could reveal an alias identity or avatar, or limit access of the caller's identity to only a few close friends or authorized contacts. Anonymity is especially valuable in applications like gaming, where there is no reason for a player to share their true identityespecially with an unknown opponent. Another condition requiring anonymous communication is in machine-to-machine or M2M, IoT or Internet-of-Things, vehicle-to-vehicle or V2V, or vehicle-to-infrastructure or V2X communication where a client doesn't want machines, gadgets and devices to be giving out contact and personal information to potentially hostile devices, agents, or cyber-pirate devices. For the extremely paranoid user, voice can also be disguised electronically so that even vocal communication can be achieved anonymously.

(737) As shown in step 1430K of FIG. 124D in response to an incoming packet, application 1335, hosted by cell phone 32, sends IP packet 1450G to signaling node S hosted on signaling server 1365. The outgoing packet requests reply routing information. In one embodiment, signaling node S can then supply the person called with the caller's true identity, whereby the SDNP application program of the person being called may reply by repeating, in the reverse direction, the entire connection process used to connect to them, i.e. contact the name server, find their SDNP or IP address, contact the signaling server, route a reply, etc. In another embodiment, the signaling server knows where the packet came from and designs a route for a reply packet to be sent without ever disclosing the contact information of the caller.

(738) Regardless of the reply method employed, in step 1430L of FIG. 124E, reply IP packet combines audio data comprising voice waves 1384B captured by microphone 1383B and converted into analog signals then converted into digital code by audio CODEC (not shown). The audio content once processed, scrambled, encrypted and packaged becomes the secure payload 1435 of IP packet 1450H routed from IP Addr CP to the SDNP gateway media node IP Addr MF. These IP addresses are recognizable on the Internet, except that payload 1435 comprises scrambled and encrypted content using SDNP zone U1 security settings, and the SDNP header contained in the payload 1435 is formatted specifically in accordance with the shared secrets for zone U1.

(739) In step 1430M the reply packet exits the secure SDNP cloud without ever executing any node-to-node hop within the SDNP cloud. In this case, gateway media node M.sub.a,f hosted by media server 1220F, converts the contents of the SDNP packet 1450H from a zone Z1 specific payload 1435 into a zone U2 payload 1436 and, using IP addresses IP Addr MF and IP Addr TB, directs IP packet 1450J to client node C.sub.2,1, hosted by tablet 33. This last-mile routing of IP packet 1450J occurs using IP addresses IP Addr MF and IP Addr TB recognizable on the Internet, but payload 1436 is scrambled and encrypted using SDNP zone U2 security settings, and the SDNP header contained in the payload 1436 is formatted specifically in accordance with the secure dynamic network protocol for zone U2. Once received by cell phone 33, SDNP enabled application 1335 then extracts the payload data and after decryption and unscrambling converts the digital code using an audio CODEC (not shown) into sound 1384B produced by speaker 1388A. In the sequence shown in steps 1430K-1430M, only one gateway media node is involved in the communication, and thus the first mile is immediately followed by the last mile.

(740) A summary of the call sequence using tri-channel communication in accordance with this invention is illustrated in FIG. 125A where, using TCP transport based IP packets 1450A and 1450B, application 1335, running on tablet 33, and name server node NS establish a dialogue, whereby, once receiving the contact information or IP address of the person being contacted, tablet 33 instructs signaling node S to place a call and establish a session with the recipient, using TCP transport-based IP packet 1450C. Thereafter, voice waves 1384A are captured, packaged and routed by media nodes to their destination, using a combination of IP packets 1450D and 1450F for the first mile and the last mile, respectively, and SDNP packet 1450E for transmission through the SDNP cloud. The resulting routing, from tablet 33 to gateway media node M.sub.a,f to a second gateway media node M.sub.a,d to cell phone 32, is shown in FIG. 125B. All transport except for node-to-node hop 1453B uses IP addresses rather than SDNP addresses. This sequence is shown in the flow chart at the bottom of FIG. 125B.

(741) The reply sequence is shown in FIG. 126A, where application 1335 in cell phone 32, using IP packet 1452G, requests signaling node S to send a reply packet to tablet 32, and the gateway media node routes the voice reply, using IP packets 1452H and 1452J. The resulting packet transport, shown in FIG. 126B, comprising hops 1453D and 1453E is almost too short, because transport occurs entirely over the Internet except for the routing through gateway media node M.sub.a,f, which enhances security only by rewriting the source and destination IP addresses and converting the data packet security settings from zone U1 to zone U2. In such an example, no node-to-node hop within the SDNP cloud occurs, which has the disadvantage of making it easier to track and correlate data packets in and out of a single node, in this case media server 1220F.

(742) In such a case it is advantageous to insert a dummy node in the data transport path to facilitate misdirection, as shown in FIG. 126C. In such a case, the routing is modified to include a second server address IP Addr MF2, either in the same server or in the same server farm as the address IP Addr MF, and to convert incoming IP packet 1452H from IP Addr CP to IP Addr MF into an outgoing IP packet 1462L from IP Addr MF2 to IP Addr TB by inserting an intermediate IP packet 1452K, which hands off packet 1452K from IP Addr MF to IP Addr MF2, or alternatively from SDNP Addr MF to SDNP Addr MF2. The port assignment also changes during the translation process. In such a case, it does not matter whether the address is an Internet IP address, a NAT address or a SDNP address, because data packet 1452K never leaves the server or server farm, i.e. it represents an internal handoff and transfer.

(743) Payload Fields

(744) Payload processing of an incoming data packet entering the SDNP client through a gateway media node is illustrated in FIG. 127, where incoming IP packet 1374B is first unpacked to extract encrypted payload comprising ciphertext 1393, then decrypted using the appropriate key from the zone in which the encryption occurred and using as needed the time or state when it occurred. The resulting payload comprises plaintext 1392 which if scrambled must also be unscrambled, again using the appropriate zone and state security settings. Next, the SDNP preamble is stripped, revealing a content data packet 1391 comprising various fields, in this case comprising a field 9 with a corresponding header Hdr 9, as well as a junk field with corresponding header Hdr J.

(745) In alternative embodiment, also shown in FIG. 127, incoming IP packet 1460 is decrypted and unscrambled, its preamble is removed, and it is parsed to produce two valid data fieldsfield 6 with corresponding header Hdr 6, and field 8 with corresponding header Hdr 8. These packets may then be merged with other fields to form new IP packets and SDNP packets accordingly.

(746) Using the nested fields data structure, packing several fields of data with their own headers into one packet's payload, is much like placing multiple boxes inside a bigger box. The process of SDNP re-packing the data, i.e. opening a box, taking out the smaller boxes and putting them into new big boxes, involves many choices in routing of data segments. To avoid packet loss, it is preferable that data segments of the same origin are not commingled into the same fields as with data segments from other data, conversations and communiqu?s, but remain uniquely separate as identified by header and arranged by sender. For example, in FIG. 128, incoming payloads 1461 and 1393, from SDNP or IP data packets (not shown), are both decrypted using decryption operation 1032, possibly using different decryption keys from different states or zones, resulting in two plaintext payloads 1392 and 1462. Mixing operation 1061 combines the payloads 1392 and 1462 and, after parsing, produces content for three fieldsfield 6 comprising packet 1464, field 8 comprising packet 1463, and field 9 comprising packet 1459, which together form data content 1470. The three packets 1459, 1463 and 1464 may be stored separately or merged into a long packet. Because of their SDNP headers, each field of data is easily identified, even though they have been removed from the SDNP or IP packet used to deliver them. Collectively, the data content 1470 represents the data present in the media node at that specific instant. The process is dynamic, with the content ever-changing as packets traverse the SDNP network. After a prescribed period of time, when there is no reason to wait for more incoming data, the data content 1470 is split into new combinations by splitting operation 1057 whereby payload 1472 contains some of the data segments from each of the three fields, i.e. data segments 9C and 9D from field 9, data segment 8B from field 8, and data segments 6C and 6D from field 6. The numbers of these fields are carried over into payload 1472. The plaintext is scrambled if desired, and then it is encrypted using encryption operation 1026 at the present state and for the current zone to produce payload 1474, ready to be assembled into a SDNP packet or an IP packet and routed on its way.

(747) Splitting operation 1057 also creates a second payload 1471, containing data segments for three fields, i.e. field 9 containing data segments 9B, 9A, 9F and 9E, field 8 containing only data segment 8F, and field 6 containing data segment 6F.

(748) As shown, all of the fields in payloads 1471 and 1472 also contain one or more junk data segments. Unless re-scrambling is executed, the scrambled payload 1471 is then encrypted using encryption operation 1026 at the present state and for the current zone to produce payload 1473, ready to be assembled into a SDNP packet or an IP packet. Similarly, payload 1472 is encrypted using encryption operation 1026 at the present state and for the current zone to produce payload 1474, ready to be assembled into a SDNP packet or an IP packet. Payload 1473 is routed to a different media node than payload 1474. In this illustration, the IP or SDNP addresses and the rest of the data packet are excluded from the illustration for the sake of clarity.

(749) The dynamic nature of re-packeting is illustrated in FIG. 129A, where at time u and corresponding state 994, payloads 1483A and 1483B, comprising data segment data from fields Fld 91 and Fld 92, respectively, are mixed using mixing operation 1061 to form hybrid payload 1484A. At time t.sub.5 and corresponding state 995, mixing operation 1061 combines hybrid payload 1484A with payload 1484B, containing data for Fld 93, to produce hybrid long payload 1485A, comprising data segments 9B, 9A, 9F and 9E in scrambled order in field 91 with header Hdr 91, data segment 9C in field 92 with Hdr 92, and data segment 9D in field 93 with Hdr 93. At time t.sub.f and state 999, application 1335, hosted by cell phone 32, processes the hybrid multi-field payload 1485A and reassembles original data sequence 1489A comprising data segments 9A through 9F arranged sequentially

(750) In some instances, shown previously herein, it may be necessary to temporarily store some data segments or fields while awaiting others to arrive. This storage operation can occur within any given node in SDNP network, including interior media nodes or gateway media nodes. Alternatively, the storage can occur within a client's application hosted on a cell phone, tablet, notebook, etc. Such an example is shown in FIG. 129B where at time t.sub.4 payloads 1483A and 1483B comprising data segments from fields 91 and 92 are mixed by mixing operation 1061 to create hybrid payload 1484A. This new payload is held in stasis in network cache 1550, either as its component fields 1485B and 1485C or as a long hybrid payload 1484A. Finally, at time t when payload 1485D arrives, the contents of network cache 1550 are released to mixing operation 1061, producing at time t.sub.6 and corresponding state 996 hybrid payload 1486A comprising data segments 9A through 9F split across fields Fld 91, Fld 92, and Fld 93. At time t.sub.f and state 999, application 1335 hosted by cell phone 32 processes the hybrid multi-field payload 1486A and reassembles original data sequence 1489A comprising data segments 9A through 9F arranged sequentially.

(751) In another embodiment of this invention, final reassembly and caching of fields occurs within application 1335 on cell phone 32, i.e. within the client's applicationnot in the SDNP cloud. As illustrated in FIG. 129C, at time t.sub.4 payloads 1483A and 1483B comprising data segments from fields 91 and 92 are mixed by mixing operation 1061 to create hybrid payload 1484A, which is immediately transferred to application 1335 in cell phone 32 and held in a secure client application cache 1551 as payloads 1484C and 1484D. When payload 1485E arrives at time t.sub.4 and is subsequently directed to application 1335 in cell phone 32 at time t.sub.5 and with corresponding state 995, then application 1335 is, at time t.sub.f, able to reassemble original data packet 1489A comprising data segments 9A through 9F arranged sequentially.

(752) A summary flow chart summarizing client reconstruction of a SDNP packet is illustrated on FIG. 129D, where a single-channel data packet 1490, comprising one or multiple ciphertext blocks is decrypted by decryption operation 1032 to produce multi-field plaintext 1491, which is unscrambled by unscrambling operation 928 to produce multi-field plaintext strings 1492A, 1492B and 1492C, which are then merged by mixing operation 1061, including parsing operation 1087 and de-junking (not-shown), to produce original data packet 1493. Finally, data packet 1493 is converted by audio CODEC 1385 into sound or voice waves 1384A.

(753) Command & Control

(754) As a final element of SDNP communication in accordance with this invention, the command and control of media nodes by the signaling nodes is a key component in insuring high QoS and low-latency delivery of real-time packets without sacrificing security or audio fidelity. One example of a basic decision tree used to determine routing and priority treatment of clients, conversations, and data packets is shown in FIG. 130. As shown, when client node C.sub.2,1, representing tablet 33, requests to place a call to signaling node S on signaling server 1365, it specifies in command and control packet 1495A not only who the caller wants to contact but the nature of the call, e.g. is it a voice call, a video call, etc., its urgency, the preferred delivery method, e.g. normal best effort, guaranteed delivery, VIP delivery, etc. Signaling node S interprets delivery request 1499A, using select delivery method (step 1500), based on the request, the client's business status, payment history or any number of business considerations. Several outcomes may result. If the customer is a VIP or preferred customer based on their volume or income potential, then the communication session will be tagged as a VIP. VIP delivery may also utilize a special performance boost known as race routing, described later in this disclosure.

(755) If the most important factor is the file is guaranteed delivery, then guaranteed packet delivery may be employed, i.e. sending multiple redundant copies of the packets and minimizing the number of node-to-node hops to minimize the risk of packet loss even if real-time performance is sacrificed. Special delivery may include customer-specific authentication procedures. Otherwise, normal SDNP routing will be employed. In FIG. 130, the output of the select delivery method (step 1500) decision, along with the address or phone number 1499B of the person to be called, is used to govern routing affecting the operation determine and rank routing options (step 1501). Once the route options are ranked, the urgency request 1499C and any special finance consideration such as rush fees are judged by the decision select packet urgency (step 1502), whereby the output may include normal, priority, urgent, and a lower cost snail option for sending data with the proviso that audio quality will not be sacrificed.

(756) Combining the routing options (step 1501) and the urgency selection (step 1502) allows the signaling node S to best select the routing for each packet, frame or data segment (step 1503). If the selected route passes through multiple zones, it will involve various security settings (step 1504) for each zone. This data comprising seeds, decryption keys 1030 and other security-related information is then combined with the node-by-node routing, splitting and mixing for meshed transport, used to generate preambles for every data packet including IP packets for the first and last mile, comprising SDNP zone U2 preamble 505A, SDNP zone U1 preamble 1505C, and multiple SDNP zone Z1 preambles for meshed transport in the SDNP, collectively represented by preamble 1505B. Preambles 1505A, 1505B, 1505C and others are then combined with IP addresses and SDNP addresses to create the various IP (Internet Protocol) and SDNP packets. These routing instructions include IP packet 1506A sent to tablet 33 detailing the routing for a call or communiqu? from client node C.sub.2,1 to the SDNP gateway media node, multiple SDNP packets 1506B sent to media servers 1118 and used for routing the call or communiqu? among the media nodes M.sub.i,j in the SDNP cloud, and IP packet 1506C, sent to cell phone 32, detailing the routing for a call or communiqu? from the SDNP gateway node to client node C.sub.1,1, representing cell phone 32. In this manner, the media nodes only need to direct the incoming payloads according to the instructions they receive from the signaling servers, a mechanism completely opposite to that of the routing procedure used in Internet-based OTT communication.

(757) For example, as stated previously, Internet routers are hosted by many different ISPs and telephone companies who do not necessarily have the best interests of a client in mind in routing their packets with the lowest propagation delay or shortest latency. In fact, unlike SDNP communications in accordance with this invention, Internet routers cannot even distinguish data packets carrying real-time audio or video from junk mail. In real-time communication, latency is critical. Delays of a few hundred milliseconds noticeably affect QoS, and delays over 500 milliseconds become unbearable for holding a coherent voice conversation. For this and numerous other reasons, the real-time performance of the SDNP network described herein constantly monitors propagation delays and chooses the best route for each real-time data packet at the time its transport ensues.

(758) As illustrated in FIG. 131 a requested routing from IP Addr TB, i.e. tablet 33, to IP Addr CP, i.e. cell phone 32 has many potential routes. Each node-to-node propagation delay, tracked and recorded in propagation delay table 1416, varies constantly. Moreover, routing a call through the least number of media servers does not necessarily result in the lowest latency communications. For example, routing a call from client node C.sub.2,1 to media node M.sub.a,f and then to client node C.sub.2,1 has a total propagation delay of 55+60=115 ms while routing the call from media node M.sub.a,f through media node M.sub.a,d instead of directly to client node C.sub.1,1, shown by the shaded path and detailed in FIG. 132A, exhibits a delay of only of 55+15+15=85 ms, which is 20% faster, even though it transits through an additional media node. In SDNP dynamic routing, signaling server S always considers the best combination of paths, not only to maintain the lowest latency but also to fragment the data and send the content using meshed transport for enhanced security. As shown, another short delay path, shown by the shaded path through media node M.sub.a,h, detailed in FIG. 132B, has a cumulative propagation delay of 25+20+15+15+15=105 msstill superior to other options despite the large number of hops involved.

(759) Another important function of command and control is in directing packet reconstruction. This function is key to mixing, splitting and rerouting SDNP packets in the cloud. FIG. 132C illustrates one embodiment of how signaling node S can communicate with a media server, in this example hosting media node M.sub.a,q to manage data packets entering and leaving a specific node. With full knowledge of all relevant security settings 1504 for an incoming SDNP packet and its payload frames, using command and control data packet 1496C signaling node S instructs media node M.sub.a,q how to process incoming SDNP packet 1497A to produce outgoing data packet 1497B. As shown, after extracting the payload 1511A, comprising multiple frames, media node M.sub.a,q, in DUM operation 1210, decrypts and unscrambles every frame from payload 1511A and every frame from the payloads in other incoming packets (not shown), based on the state information 920, seeds, 929, and decryption keys 1030 used when each of them was created, and then mixes all the incoming fields to make a long packet, in this case represented by all the independent frames collectively as data frames 1512 and individually as data frames 1, 6, 9, 12, 23 and 31, respectively.

(760) This data is then fed into SDNP zip sorter 1310 to sort the frames into groups of frames, each group having a common destination on its next hop in the SDNP cloud, all in accordance with routing information in the SDNP packet 1506B supplied previously by the signaling node S for each frame or SDNP packet in response to the call information specified in command and control packet 1495A. SSE operation 1213 then splits the frames into the groups having common destinations, using current state 920 information, updated seeds 929, and new decryption keys 1030. One such payload, payload 1511, containing data for frames 1,9, and 23, is destined for media node M.sub.a,j, whereas the previous payload 1511A comprised data for frames 1, 6 and 9. So, as instructed by signaling node S, media node M.sub.a,q removed the frame 6 data and replaced it with the frame 23 data to make payload 1511B, which it assembled into outgoing SDNP packet 1487B and sent onward to media node M.sub.a,j.

(761) Using the 7-layer OSI model, the SDNP connection shown in FIG. 133A represents a secure gateway-to-gateway tunnel 1522, supporting end-to-end secure communication 1529 between respective SDNP applications 1335 hosted on only two clients, in this case tablet 33 and cell phone 32. In embodiments of this invention, physical and data link layers 1525 do not typically involve any special design for realizing SDNP operation. Network Layer 3, however, operates completely differently than the Internet because the SDNP controls the routing of every single hop within the SDNP cloud for security, to minimize latency, and to offer the best possible QoS. Transport Layer 4, while it uses TCP for control and an augmented version of UDP for real-time data, employs contextual transport, changing its methods and its priorities based on some knowledge as to what the SDNP packet, payload or frame is and what priority it has Session Layer 5 is unique to SDNP operation as well, where command and control informationcommunicated either through command and control packets sent on the media channel or on the signal channel-determines the management of every session, including routing, quality, delivery conditions, and priority.

(762) In SDNP communication Presentation Layer 6 executes network hop-by-hop encryption and scrambling, unrelated to the client's own encryption.

(763) In Application Layer 7, SDNP communication is again unique because any SDNP-enabled application must be able to mix and restore fragmented data, and to know what to do if part of a fragmented payload does not arrive, again contextual transport.

(764) All of the above security and performance of the disclosed SDNP network are achieved without the use of client encryption and private key management. If a client's application is also encrypted, e.g. a private company's security, then the VPN-like tunneling is combined with the data fragmentation to make a new type of secure communicationfragmented tunneled data, a hybrid of Presentation Layer 6 and Application Layer 7, shown in FIG. 133B.

(765) One unique aspect of SDNP communication in accordance with this invention is the example of race routing shown in FIG. 134. Since the SDNP network is built on meshed transport of fragmented data, there is no overhead involved in sending fragmented data fields across the meshed network in duplicate or triplicate. Conceptually, to achieve the shortest possible latency while not sacrificing security, a payload is divided into sub-packets and organized into two complementary frames. Rather than sending one frame by one route and the second frame by another, in race routing multiple copies of each frame are sent over different routes, and the first one to arrive at its destination is the one used. The copies that arrive later are simply discarded. For example, as shown frame 91 is sent over two paths, specifically paths 1540 and 1541, while frame 92 is also sent by multiple paths, paths 1541 and 1543. Whichever combination of paths is the first to deliver one frame-91 payload and one frame-92 payload, that is the combination that will be used.

SUMMARY

(766) The foregoing disclosure illustrates the numerous advantages in performance, latency, quality, security, and privacy achieved by SDNP communication in accordance with this invention. Table FIG. 135 compares the disclosed secure dynamic network and protocol (SDNP) to over-the-top or OTT carriers, virtual private networks or VPNs, and peer-to-peer or PTP networks. As revealed by the table, all the competing and prior art communication methods rely on transport over one route at a time, relying solely on encryption to protect the content of the communication. Encryption in a VPN aside, all of the existing communication methods expose the source and destination addresses of the communicating parties, enabling phishing, sniffing, and profiling as a vulnerability to cyber-assaults. In all of them security is static, remaining constant as a packet traverses the network. Since none of the prior art methods control the routing of a communication, they cannot detect whether or not the communication has been hijacked; and they cannot control the latency or real-time performance of the network. Moreover, OTT and PTP networks have no guarantee a high-bandwidth router will even be available to support a call, leading to constant shifts in sound quality and incessant call drops. Lastly, in every case except the disclosed SDNP communication method and meshed network, should a hacker break an encryption code, the hacker can use the knowledge to inflict significant damage before the security breach is discovered and will therefore be able to read or hear the full contents of private or personal communications.

(767) In the disclosed SDNP network, even in the event that a cyber attacker breaks the encryption, the data in any one packet is garbled, incomplete, mixed with other messages, and scrambled out of orderbasically the content of any SDNP packet is useless except to the person for which it was intended. Moreover, even if the network's encryption were broken, a challenge that can take years to complete, even with quantum computing, one-tenth of a second later the dynamic encryption of every packet traversing the entire SDNP cloud changes. This means that a would-be hacker must start all over every 100 ms. With such dynamic methods, a five-minute conversation, even if it were completely available in a single data string, would take hundreds of years to decode. Beyond this, with the addition of data fragmentation, dynamic scrambling, and dynamic mixing and rerouting, any benefits to be gained by breaking the encryption would be totally illusory.

(768) The combination of the multiple levels of security realized by the secure dynamic network and protocol described herein, including dynamic scrambling, fragmented data transport, anonymous data packets, and dynamic encryption far exceeds the security offered by simple static encryption. In SDNP communication as disclosed herein, data packets from a single conversation, dialog, or other communication do not travel across a single route but are split into incomprehensible snippets of meaningless data fragments, scrambled out of sequence and sent over multiple paths that change continuously in content, by mix, and by the data's underlying security credentials. The resulting communication method represents the first hyper-secure communication system.