AU2018249485B2 - Methods and apparatus for hypersecure last mile communication - Google Patents

Abstract

A variety of techniques for concealing the content of a communication between a client device, such as a cell phone or laptop, and a network or cloud of media nodes are disclosed. Among the techniques are routing data packets in the communication to different gateway nodes in the cloud, sending the packets over different physical media, such as an Ethernet cable or WiFi channel, and disguising the packets by giving them different source addressees. Also disclosed are a technique for muting certain participants in a conference call and a highly secure method of storing data files.

Description

1 Methods and Apparatus for HyperSecure Last Mile Communication

2 Cross Reference to Related Applications 3 This application claims the priority of U.S. Provisional Application 62/480,696, 4 filed April 3, 2017, and is a continuation-in-part of U.S. Application No. 14/803,869, titled "Secure Dynamic Communication Network And Protocol," filed July 20, 2015, 6 which in turn claimed the priority of U.S. Provisional Application No. 62/107,650, filed 7 January 26, 2015. 8 Each of the foregoing applications is incorporated herein by reference in its 9 entirety.

11 Field of the Invention 12 This invention relates to the methods and apparatus to facilitate HyperSecure "last 13 mile" communication between a 8device and a gateway to a network or cloud. 14 Background of the Invention 16 Improving means of communication have fueled the progress of civilization from 17 mankind's earliest beginnings. From the use of couriers and messengers traveling by foot 18 or horseback; through mail postal delivery by train, truck and airplane; to the advent of 19 the telegram and telegraph, telephone, radio, television, computers, the cell phone; the Internet, email and World Wide Web; and more recently, through social media, voice 21 over-Internet, machine-to-machine (M2M) connectivity, the Internet of Things (IoT), and 22 the Internet of Everything (IoE), communication has always led the way in exploiting the 23 newest technologies of the day. With each new generation of telecommunications 24 technology employed, the number of people connected and the rate by which information is transferred among them has also increased. 26 The effect of this trend is that humanity is more connected than at any time in 27 history, with people trusting and relying on communication technology to safely and 28 reliably deliver their private, personal, family, and financial information to only those to 29 which they intend to contact. Knowledge and information can now be distributed in seconds to millions of people, and friends and family can contact one another half way

1 around the world as casually as pushing a button. It is often said, "the world has become 2 a very small place." 3 While such progress is tremendously beneficial to everyone, there are also 4 negative consequences of our heavy reliance on technology. It is not surprising that when the communication system fails to perform, e.g. during an earthquake or severe weather, 6 people become disoriented or even panicked by their being "unplugged", even if only 7 temporarily. The quality of service, or QoS, of a communication system or media is then 8 a critical measurement of a communication network's performance. Peoples' peace-of 9 mind, financial assets, identity, and even their very lives rely on dependable and secure communication. 11 Another key consideration of a communication network is its ability to insure 12 privacy, safety, and security to the client using it. As communication technology has 13 evolved, so too has the sophistication of criminals and "hackers" intending to inflict 14 mischief, disrupt systems, steal money, and accidentally or maliciously harm others. Credit card fraud, stolen passwords, identity theft, and the unauthorized publicizing of 16 confidential information, private pictures, files, emails, text messages, and private tweets 17 (either stolen to embarrass or blackmail victims) are but a few examples of modern 18 cyber-crime. 19 Notable examples of privacy violations and cybercrime at the time of this patent application are listed below to highlight the epidemic proportion of the security problem 21 in today's open communication networks (arranged chronologically): 22 23 • "Target: Stolen Information Involved at Least 70 million People," 24 CNBC 10 Jan 2014 • "Hackers Made Smart Fridge and TV Send Malicious emails," 26 BGR (www.bgr.com) 20 Jan 2014 27 • "Nest Google Privacy Row Resumes as Thermostat Hacked," 28 Slash Gear (www.slashgear.com) 24 Jun 2014 29 • "Account Hijackings Call Line's Data Security into Question. Line, the free call and messaging app, has been rocked by a recent spate of data security

1 breaches. The app has seen hundreds of user accounts illegally accessed by parties 2 other than the accounts' users," Nikkei Asian Review, 2 Jul 2014 3 • "Ordinary Americans Caught up in NSA Data Sweep, Report 4 Claims," AP 6 Jul 2014 • "Smart LED Light Bulbs Leak Wi-Fi Passwords," BBC News 8 Jul 6 2014 7 • "Six People Charged Over StubHub Scam for Prime Tickets. 8 StubHub was targeted by hackers who used stolen passwords and credit card 9 numbers to buy and sell thousands of tickets for pop-music concerts and Yankees games, New York authorities said", Bloomberg, 24 Jul 2014 11 • "'Internet Of Things' Very Susceptible To Hacking, Study 12 Shows," InternationalBusiness Times (www.ibtimes.com) 4 Aug 2014 13 • "Russian Hackers Amass Over a Billion Internet Passwords", New 14 York Times 5 Aug 2014 • "New Leaker Disclosing U.S. Secrets, Government Concludes," 16 CNN 6 Aug 2014 17 • "Hackers Root Google's Nest Thermostat in 15 seconds," The 18 Enquirer (www. theinquirer.net) 11 Aug 2014 19 • "Dairy Queen Hacked by Same Malware that Hit Target," ChristianScience Monitor 29 Aug 2014 21 • "Celebrity Victims in Leak of Nude Photos - Security 22 Vulnerability in iCloud Accounts," CBSNews, 1 Sep 2014 23 • "Home Depot May be the Latest Target of Credit Card Breach... 24 Home Depot breach could be much larger than Target (40M cards stolen over 3 weeks)," Fortune, 2 Sep 2014 26 • "Mysterious Fake Cellphone Towers Are Intercepting Calls All 27 Over The US," Business Insider 3 Sep 2014 28 • "Hack Attack: From Banks to Retail, Signs of Cyberwarfare?" 29 Yahoo Finance 3 Sep 2014 • "Home Depot Confirms Payment System Hacked In U.S. And 31 Canadian Stores," Fox News 9 Sep 2014

1 • "Yahoo Waged Court Fight with U.S. Government Over 2 Surveillance," CBSIAP 11 Sep 2014 3 • "Your Medical Record is Worth More to Hackers than Your Credit 4 Card," Reuters 24 Sep 2014 • "Red Alert: HTTPS Has Been Hacked. Browser exploit against 6 SSL/TLS (BEAST) attack will rank among the worst hacks [sic] because it 7 compromises browser connections hundreds of millions of people rely on every 8 day," InfoWorld, 26 Sep 2014 9 • "Sony Cyberattack, First A Nuisance, Swiftly Grew Into a Firestorm," New York Times, 30 Dec 2014 11 12 In what appears to be an escalating pace of cybercrime, security breaches, identity 13 thefts, and privacy invasions, it begs the question, "how are all these cyber-attacks 14 possible and what can be done to stop them?" At the same time that society seeks greater privacy and security, consumers also want greater connectivity, cheaper higher-quality 16 communication, and more convenience in conducting financial transactions. 17 To understand the performance limitations and vulnerabilities in modern 18 communication networks, data storage, and connected devices, it is first importa3nt to 19 understand how today's electronic, radio, and optical communication operates, transports, and stores data including files, email, text, audio, and video images. 21 22 Circuit-Switched Telephonic Network Operation 23 Electronic communication involves a variety of hardware components or devices 24 connected into networks of wires, radio, microwave, or optical fiber links. Information is passed from one device to others by sending electrical or electromagnetic energy through 26 this network, using various methods to embed or encode informational "content" into the 27 data stream. Theoretically, the laws of physics set the maximum data rate of such 28 networks at the speed of light, but in most cases practical limitations in data encoding, 29 routing and traffic control, signal-to-noise quality, and overcoming electrical, magnetic and optical noise and unwanted parasitics disturb or inhibit information flow, limiting the 31 communication network's capability to a fraction of its ideal performance.

1 Historically, electronic data communication was first achieved using dedicated 2 "hardwired" electrical connections forming a communication "circuit" between or among 3 two or more electrically connected devices. In the case of a telegraph, a mechanical 4 switch was used to manually make and break a direct current (DC) electrical circuit, magnetizing a solenoid which in turned moved a metallic lever, causing the listening 6 device or "relay" to click in the same pattern that the sender depressed the switch. The 7 sender then used an agreed upon language, i.e. Morse code, to encode information into 8 the pulse stream. The listener would likewise need to understand Morse code, a series of 9 long and short pulses, called dots and dashes, to interpret the message. Later, Alexander Graham Bell developed the first telephone using the concept of 11 an "undulating current", now referred to as alternating current (AC), in order to carry 12 sound through an electrical connection. The telephone network comprised two magnetic 13 transducers connected by an electrical circuit where each magnetic transducer comprised 14 a movable diaphragm and coil, or "voice coil", surrounded by a fixed permanent magnet enclosure. When speaking into the transducer, changes in air pressure from the sound 16 causes the voice coil to move back and forth within the surrounding magnetic field 17 inducing an AC current in the coil. At the listener's end, the time-varying current flowing 18 in the voice coil induces an identical waveform and time-varying magnetic field opposing 19 the surrounding magnetic field causing the voice coil to move back-and-forth in the same manner as the transducer capturing the sound. The resulting movement reproduces the 21 sound in a manner similar to the device capturing the sound. In the modern vernacular, 22 when the transducer is converting sound into electrical current, it is operating as a 23 microphone and when the transducer is converting electrical current into sound it is 24 operating as a speaker. Also, because the conducted electrical signal is analogous to the audio waveform carried as an elemental pressure wave in air, i.e. sound, today such 26 electrical signals are referred to as analog signals or analog waveforms. 27 Since the transducer, as described, is used both for speaking and for listening, in 28 conversation both parties have to know when to speak and when to listen. Similar to two 29 tin cans connected by a string, in such a system, a caller cannot talk and listen at the same time. While such one-way operation, called "half-duplex" mode, may sound archaic, it is

1 actually still commonly used in radio communication today in walkie-talkies, and in 2 modern telephony by the name "push-to-talk" or PTT. 3 Later full-duplex (i.e., two-way or send-and-receive) telephones with separate 4 microphones and speakers became commonplace, where the parties could speak and listen at the same time. But even today care is required in operating full-duplex 6 telephonic communication to prevent feedback, a condition where a receiver's sound is 7 picked up by its microphone and fed back to the caller resulting in confusing echoes and 8 sometimes uncomfortable whistling sounds - problems especially plaguing long distance 9 telephonic communication. Early telegraphic and telephonic systems suffered from another issue, one of 11 privacy. In these early incarnations of communication networks, everyone connected to 12 the network hears everything communicated on the circuit, even if they don't want to. In 13 rural telephone networks, these shared circuits were known as "party lines". The phone 14 system then rapidly evolved into multi-line networks where dedicated circuits connected a telephone branch office directly to individual customers' phones. Within the branch 16 exchange office, a system operator would manually connect callers to one another 17 through a switchboard using jumper cables, and also had the capability of connecting one 18 branch to others to form the first "long distance" phone call services. Large banks of 19 relays forming telephonic "switch" networks gradually replaced human operators, which was subsequently replaced by electronic switches comprising vacuum tubes. 21 After Bell Laboratories developed the transistor in the late 1950s, telephone 22 switches and branch exchanges replaced their fragile and hot vacuum tubes with cool 23 running solid-state devices comprising transistors and ultimately integrated circuits. As 24 the network grew, phone numbers expanded in digits from a seven-digit prefix and private number to include area codes and ultimately country codes to handle international 26 calls. Copper cables carrying voice calls soon covered the world and crossed the oceans. 27 Despite the magnitude of the network, the principle of operation remained constant, that 28 calls represented a direct electrical connection or "circuit" between the callers with voice 29 carried by analog signals and the routing of the call determined by telephone switches. Such a telephonic system eventually came to be known as a "circuit-switched telephonic 31 network", or colloquially as the plain old telephone system or POTS. Circuit switched

1 telephony reached its peak adoption in the 1980s and thereafter relentlessly has been 2 replaced by "packet-switched telephony" described in the next section. 3 Evolving nearly in parallel to the telephone network, regular radio communication 4 commenced with radio broadcasting in the 1920s. The broadcast was unidirectional, emanating from radio broadcast stations on specific government-licensed frequencies, 6 and received by any number of radio receivers tuned to that specific broadcast frequency 7 or radio station. The broadcasted signal carried an analog signal using either amplitude 8 modulation (AM) or later by frequency modulation (FM) methods, each on dedicated 9 portions of the licensed radio spectrum. In the United States, the Federal Communications Commission or FCC evolved in order to manage the assignment and 11 regulation of such licensed bands. The broadcast concept was expanded into airing 12 television programs using radio transmission, initially comprising black and white 13 content, then in color. Later, television signals could also be carried to people's homes 14 either by microwave satellite dishes or through coaxial cables. Because any listener tuned to the specific broadcast frequency can receive the broadcast, the term "multicast" is now 16 used for such unidirectional multi-listener communication. 17 Concurrent with advent of radio broadcasting, the first two-way communication 18 commenced with commercial and military ocean ships, and by the time of World War II, 19 radios had evolved into walkie-talkie handheld radio transceivers, devices combining transmitters and receivers into single unit. Like telephony, early two-way radio 21 transmission, operated in "simplex" mode, allowing only one radio to broadcast on a 22 single radio channel while others listened. By combining transmitters and receivers on 23 different frequencies, simultaneous transmission and reception became possible at each 24 end of the radio link, enabling full-duplex mode communication between two parties. To prevent overlapping transmissions from multiple parties, however, a protocol 26 called half-duplex or push-to-talk is commonly used for channel management, letting 27 anyone exclusively transmit on a specific channel on a first-come first serve basis. 28 Industry standard radio types using analog modulation include amateur (ham or CB) 29 radio, marine VHF radio, UNICOM for air traffic control, and FRS for personal walkie talkie communication. In these two-way radio networks, radios send their data over 31 specific frequency "channels" to a central radio tower, where the tower amplifies and

1 repeats the signal, sending it on to the entire radio network. The number of available 2 frequencies carrying information over the broadcast area sets the total bandwidth of the 3 system and the number of users able to independently communicate on the radio network 4 at one time. In order to expand the total capacity of the radio network to handle a greater 6 number of callers, the concept of a cellular network, one where a large area is broken into 7 smaller pieces or radio "cells" was demonstrated in the 1970s and reached widespread 8 adoption within a decade thereafter. The cellular concept was to limit the broadcast range 9 of a radio tower to a smaller area, i.e. to a shorter distance, and therefore be able to reuse the same frequency bands to simultaneously handle different callers present in different 11 cells. To do so, software was created to manage the handoff of a caller passing from one 12 cell into an adjacent cell without "dropping" and suddenly disconnecting the call. Like 13 POTS, two-way radio, as well as radio and television broadcasting, the initial cellular 14 networks were analog in nature. To control call routing, the telephone number system was adopted to determine the proper wireless electrical connection. This choice also had 16 the benefit that it seamlessly connected the new wireless cellular network to the "wire 17 line" plain old telephone system, providing interconnection and interoperability across 18 the two systems. 19 Starting in the 1980s, telephonic and radio communication, along with radio and TV broadcasting began an inexorable migration from analog to digital communication 21 methods and formats, driven by the need to reduce power consumption and increase 22 battery life, to improve quality with better signal-to-noise performance, and to begin 23 addressing the need to carry data and text with voice. Radio formats such as EDACS and 24 TETRA emerged capable of concurrently enabling one-to-one, one-to-many, and many to-many communication modes. Cellular communication also quickly migrated to digital 26 formats such as GPRS, as did TV broadcasting. 27 By 2010, most countries had ceased, or were in the process of ceasing, all analog 28 TV broadcasting. Unlike broadcast television, cable TV carriers were not required to 29 switch to the digital format, maintaining a hybrid composite of analog and digital signals till as recently as 2013. Their ultimate migration to digital was motivated not by 31 government standards, but by commercial reasons to expand the number of available

1 channels of their network, to be able to deliver HD and UHD content, to offer more pay 2 per-view (PPV, also know an as "unicast") programming, and to enable high-speed 3 digital connectivity services to their customers. 4 While it is common to equate the migration of global communication networks from analog to digital formats with the advent of the Internet and more specifically with 6 the widespread adoption of the Internet protocol (IP), the switch to digital formats 7 preceded the commercial acceptance of IP in telephony, enabling, if not catalyzing, the 8 universal migration of communication to IP and "packet-switched networks" (described 9 in the next section). The resulting evolution of circuit-switched telephony is schematically, as a 11 "public switched telephone network" or PSTN comprising an amalgamation of radio, 12 cellular, PBX, and POTS connections and sub-networks, each comprising dissimilar 13 technologies. The network includes PSTN gateways connected by high bandwidth trunk 14 lines and, by example, connected through wire-line connections to POTS gateways, cellular network base stations PBX and two-way radio networks. Each sub-network 16 operates independently, driving like-kind devices. 17 The PSTN also connects to circuit-switched cellular networks over base stations 18 17 running AMPS, CDMA and GSM analog and digital protocols. Through cellular 19 towers, circuit-switched cellular network base stations connect using standardized cellular radio frequencies of cellular links to mobile devices such as cell phones. In the 21 case of GPRS networks, an enhancement to GSM, the circuit-switched cellular network 22 base stations may also connect to tablets, concurrently delivering low speed data and 23 voice. Two-way radio networks such as TETRA and EDACS connect the PSTN to 24 handheld radios and larger in-dash and desktop radios via high-power radio towers and cellular link. Such two-way radio networks, commonly used by police officers, 26 ambulances, paramedics, fire departments, and even port authorities, are also referred to 27 as professional communication networks and services, and target governments, 28 municipalities, and emergency responders rather than consumers. (Note: As used herein, 29 the terms "desktop," "tablet' and "notebook" are used as a shorthand reference to the computers having those names.)

1 Unlike POTS gateways, cellular network base stations, and PBX which use 2 traditional phone numbers to complete call routing, two-way radio network uses 3 dedicated RF radio channels (rather than phone numbers) to establish radio links between 4 towers and the mobile devices it serves. As such, professional radio communication services remain distinct and uniquely dissimilar from consumer cellular phone networks. 6 As such, PSTN networks flexibly interconnect sub-networks of diverse 7 technologies. It is this very diversity that defines an intrinsic weakness of today's circuit 8 switched networks - interoperability among sub-networks. Because the various sub 9 networks do not communicate with any common control protocol or language, and since each technology handles the transport of data and voice differently, the various systems 11 are essentially incompatible except for their limited capability of placing a phone call 12 through the PSTN backbone or trunk lines. For example, during the September 11 13 terrorist attack on the World Trade Center in New York City, many emergency 14 responders from all over the USA flocked to Manhattan in an attempt to help fight the disaster, only to learn their radio communication system and walkie-talkies were 16 incompatible with volunteers from other states and cities, making it impossible to manage 17 a centralized command and control of the relief effort. With no standardization in their 18 radio's communication protocol, their radios simply couldn't connect to one another. 19 Moreover with the direct electrical and RF connections of circuit switched telephonic networks, especially using analog or unsecured digital protocols, it is simple 21 matter for a hacker with a RF scanner to find active communication channels and to sniff, 22 sample, listen, or intercept the conversations occurring at the time. Because the PSTN 23 forms a "continuously on" link or circuit between the parties communicating, there is 24 plenty of time for a hacker to identify the connection and to "tap it", either legally by governments operating under a federal court ordered wiretap, or criminally by 26 cybercriminals or governments performing illegal, prohibited, or unsanctioned 27 surveillance. The definition of legal and illegal spying and surveillance and any 28 obligation for compliance for cooperation by a network operator varies dramatically by 29 country and has been a heated point of contention among global companies such as Google, Yahoo, and Apple operating across numerous international boundaries. 31 Communication networks and the Internet are global and know no borders or boundaries,

1 yet laws governing such electronic information are local and subject to the jurisdictional 2 authority of the government controlling domestic and international communication and 3 commerce at the time. 4 Regardless of its legality or ethics, electronic snooping and surveillance today is commonplace, ranging from the monitoring of ubiquitous security cameras located at 6 every street corner and overhead in every roadway or subway, to the sophisticated 7 hacking and code cracking performed by various countries' national security divisions 8 and agencies. While all networks are vulnerable, the antiquity and poor security 9 provisions of PSTNs render them especially easy to hack. As such, a PSTN connected to even a secure modem network represents a weak point in the overall system, creating 11 vulnerability for security violations and cybercrimes. Nonetheless, it will still take many 12 years, if not decades, to retire the global PSTN network and completely replace it with 13 IP-based packet-switched communication. Such packet-based networks (described here 14 below), while more modern than PSTNs, are still unsecure and subject to security breaks, hacks, denial of service attacks, and privacy invasions. 16 17 Packet-Switched Communication Network Operation 18 If two tin cans connected by a string represent a metaphor for the operation of 19 modern day circuit-switched telephony, then the post office represents the similar metaphor for packet-switch communication networks. In such an approach, text, data, 21 voice, and video are converted into files and streams of digital data, and this data is then 22 subsequently parsed into quantized "packets" of data to be delivered across the network. 23 The delivery mechanism is based on electronic addresses that uniquely identify where the 24 data packet is going to and where it is coming from. The format and communication protocol is also designed to include information as to the nature of the data contained in 26 the packet including content specific to the program or application for which it will be 27 used, and the hardware facilitating the physical links and electrical or radio connections 28 carrying the packets. 29 Born in the 1960s, the concept of packet switching networks was created in the paranoiac era of the post Sputnik cold war. At that time, the US Department of Defense 31 (DoD) expressed concerns that a spaced-based nuclear missile attack could wipe out the

1 entire communication infrastructure of the United States, disabling its ability to respond 2 to a USSR preemptive strike, and that the vulnerability to such an attack could actually 3 provoke one. So the DoD sponsored the creation of a redundant communication system 4 or grid-like "network", one where the network's ability to deliver information between military installations could not be thwarted by destroying any specific data link or even 6 numerous links within the network. The system, known as ARPANET, became the parent 7 of the Internet and the proverbial Eve of modern digital communications. 8 Despite the creation of the packet-switched network, explosive growth of the 9 Internet didn't occur until the 1990s when the first easy-to-use web browser Mosaic, the advent of hypertext defined web pages, the rapid adoption of the World Wide Web, and 11 the widespread use of email, collectively drove global acceptance of the Internet 12 platform. One of its fundamental tenets, lack of central control or the need for a central 13 mainframe, propelled the Internet to ubiquity in part because no country or government 14 could stop it (or even were fully aware of its global implications) and also because its user base comprised consumers using their newly acquired personal computers. 16 Another far reaching implication of the Internet's growth was the standardization 17 of the Internet Protocol (IP) used to route data packets through the network. By the mid 18 1990s, Internet users realized that the same packet-switched network that carries data 19 could also be used to carry voice, and soon thereafter "voice over Internet protocol" or VoIP was born. While the concept theoretically enabled anyone with Internet access to 21 communicate by voice over the Internet for free, propagation delays across the network, 22 i.e. latency, rendered voice quality poor and often unintelligible. While delay times have 23 improved with the adoption of high-speed Ethernet links, high-speed WiFi connectivity, 24 and 4G data to improve connection quality in the "last-mile", the Internet itself was created to insure accurate delivery of data packets, but not to guarantee the time required 26 to deliver the packets, i.e. the Internet was not created to operate as a real-time network. 27 So the dream of using the Internet to replace expensive long distance 28 telecommunication carriers or "telco's" has remained largely unfulfilled despite the 29 availability of "over-the-top" (OTT) providers such as Skype, Line, KakaoTalk, Viper, and others. OTT telephony suffers from poor quality of service (QoS) resulting from 31 uncontrolled network latency, poor sound quality, dropped calls, echo, reverberation,

1 feedback, choppy sound, and oftentimes the inability to even initiate a call. The poor 2 performance of OTT communication is intrinsically not a weakness of the VoP based 3 protocol but of the network itself, one where OTT carriers have no control over the path 4 which data takes or the delays the communication encounters. In essence, OTT carriers cannot insure performance or QoS because OTT communication operates as an Internet 6 hitchhiker. Ironically, the companies able to best utilize VoIP based communications 7 today are the long distance telephone carriers with dedicated low-latency hardware-based 8 networks, the very telco's that have the least motivation to do so. 9 Aside from its intrinsic network redundancy, one of the greatest strengths of packet-switched communication is its ability to carry information from any source to any 11 destination so long that the data is arranged in packets consistent with the Internet 12 Protocol and provided that the communicating devices are connected and linked to the 13 Internet. Internet Protocol manages the ability of the network to deliver the payload to its 14 destination, without any care or concern for what information is being carried or what application will use it, avoiding altogether any need for customized software interfaces 16 and expensive proprietary hardware. In many cases, even application related payloads 17 have established predefined formats, e.g. for reading email, for opening a web page on a 18 browser, for viewing a picture or video, for watching a flash file or reading a PDF 19 document, etc. Because its versatile file format avoids any reliance on proprietary or company 21 specific software, the Internet can be considered an "open source" communication 22 platform, able to communicate with the widest range of devices ever connected, ranging 23 from computers, to cell phones, from cars to home appliances. The most recent phrase 24 describing this universal connectivity is the "Internet of Everything" or IoE. As shown, a large array of computers include high-speed cloud servers and cloud 26 data storage interconnected by high bandwidth connections, typically optical fiber, 27 among with countless other servers (not shown) to form the Internet cloud. The cloud 28 metaphor is appropriate because there is no well-defined boundary defining which 29 servers are considered part of the cloud and which ones are not. On a daily and even on a minute-to-minute basis, servers come online while others may be taken offline for 31 maintenance, all without any impact to the Internet's functionality or performance. This

1 is the benefit of a truly redundant distributed system - there is no single point of control 2 and therefore no single point of failure. 3 The cloud may be connected to the user or connected device through any variety 4 of wire-line, WiFi or wireless links. Wireless packet-switched capable telephonic communication comprises cellular protocols 3G including HSUPA and HSDPA, as well 6 as 4G/LTE. LTE, or long-term-evolution, refers to the network standards to insure 7 interoperability with a variety of cellular protocols including the ability to seamlessly 8 hand-off phone calls from one cell to another cell even when the cells are operating with 9 different protocols. Note: As a matter of definition, as used herein "last-mile" refers to the link between any type of client device, such as a tablet, desktop or cell phone, and a 11 cloud server. Directionally, the term "first-mile" is sometimes also used to specify the 12 link between the device originating the data transmission and the cloud server. In such 13 cases the "last-mile" link is also the "first-mile" link. 14 For shorter distance communication, WiFi access points connect smartphones,, tablets, notebooks, desktops or connected appliances and may be used in localized 16 wireless applications in homes, cafes, restaurants, and offices. WiFi comprises 17 communication operating in accordance with IEEE defined standards for single-carrier 18 frequency specifications 802.1la, 802.1lb, 802.11g, 802.11n, and most recently for the 19 dual frequency band 802.11ac format. WiFi security, based on a simple static login key, is primarily used to prevent unauthorized access of the connection, but is not intended to 21 indefinitely secure data from sniffing or hacking. 22 Wire-line distribution unit, i.e. routers, may connect by fiber, coaxial cable, or 23 Ethernet to a variety of devices including notebooks, desktops, phones,, televisions or by 24 twisted pair copper wire phone lines to point-of-sale terminal serving immobile or fixed wire-line connected markets including hotels, factories, offices, service centers, banks, 26 and homes. The wire-line connection may comprise fiber or coaxial cable distribution to 27 the home, office, factory, or business connected locally though a modem to convert high 28 speed data (HSD) connection into WiFi, Ethernet, or twisted pair copper wire. In remote 29 areas where fiber or cable is not available, digital subscriber line (DSL) connections are still used but with dramatically compromised data rates and connection reliability. 31 Altogether, counting access through wireless, WiFi, and wire-line connections, the

1 number of Internet connected objects is projected to reach 20 billion globally by the year 2 2020. 3 In contrast to circuit switched networks that establish and maintain a direct 4 connection between devices, packet-switched communications uses an address to "route" the packet through the Internet to its destination. As such, in packet-switched 6 communication networks, there is no single dedicated circuit maintaining a connection 7 between the communicating devices, nor does data traveling through the Internet travel in 8 a single consistent path. Each packet must find its way through the maze of 9 interconnected computers to reach its target destination. In routing of an IP packet from a notebook to a desktop using packet-switched 11 network communication for example the first data packet sent from the notebook to a 12 local WiFi router via wireless connection is directed toward array of DNS servers, DNS 13 being an acronym for domain name servers. The purpose of the array of DNS servers is 14 to convert the textual name or phone number of the destination device, in this case the desktop, into an IP address. Once identified, the IP address is passed from the array of 16 DNS servers back to the source address, i.e. to the notebook. This address, which clearly 17 identifies the communicating device, is used in routing the data packets through the 18 network. 19 Thereafter the notebook assembles its IP data packets and commences sending them sequentially to their destination, for example first through WiFi radio to a local 21 WiFi router and then subsequently across the network of routers and servers acting as 22 intermediary routers and computer servers to its destination. Together the routers and 23 computer servers network operating either as nodes in the Internet or as a point of 24 presence or POP, i.e. gateways of limited connectivity capable of accessing the Internet. While some routers or servers acting as a POP connect to the Internet through only a 26 small number of adjacent devices, other servers are interconnected to numerous devices, 27 and are sometimes referred to as a "super POP". For clarity's sake it should be noted the 28 term POP in network vernacular should not be confused with the application name POP, 29 or plain old post office, used in email applications. Each router, or server acting as a router, contains in its memory files a routing 31 table identifying the IP addresses it can address and possibly also the addresses that the

1 routers above it can address. These routing tables are automatically downloaded and 2 installed in every router when it is first connected to the Internet and are generally not 3 loaded as part of routing a packet through the network. When an IP packet comes into a 4 router, POP or super POP, the router reads enough of the IP address, generally the higher most significant digits of the address, to know where to next direct the packet on its 6 journey to its destination. For example a packet headed to Tokyo from New York may be 7 routed first through Chicago then through servers in San Francisco, Los Angeles, or 8 Seattle before continuing on to Tokyo. Since the number of routers a packet traverses and 9 the available data rate of each of the connections between routers varies by infrastructure and by network traffic and loading, there is no way to determine aprioriwhich path is 11 fastest or best. 12 Unlike in circuit-switched telephonic communication that establishes and 13 maintains a direct connection between clients, with packet-switched data, there is no 14 universal intelligence looking down at the Internet to decide which path is the best, optimum, or fastest path to route the packet nor is there any guarantee that two successive 16 packets will even take the same route. As such, the packet "discovers" its way through 17 the Internet based on the priorities of the companies operating the routers and servers the 18 packet traverses. Each router, in essence, contains certain routing tables and routing 19 algorithms that define its preferred routes based on the condition of the network. For example, a router's preferences may prioritize sending packets to other routers owned by 21 the same company, balancing the traffic among connections to adjacent routers, finding 22 the shortest delay to the next router, directing business to strategic business partners, or 23 creating an express lane for VIP clients by skipping as many intermediate routers as 24 possible. When a packet enters a router, there is no way to know whether the routing choices made by the specific POP were made in the best interest of the sender or of the 26 network server operator. 27 So in some sense, the route a packet takes is a matter of timing and of luck. In the 28 previous New York to Tokyo routing example, the routing and resulting QoS can vary 29 substantially based on even a small perturbation in the path, i.e. in non-linear equations the so-called "butterfly effect". Consider the case where the packet from New York goes 31 through "router A" in Chicago and because of temporary high traffic in California, it is

1 forwarded to Mexico City rather than to California. The Mexico City router then in turn 2 forwards the IP packet to Singapore, from where it is finally sent to Tokyo. The very next 3 packet sent is routed through Chicago "router B", which because of low traffic at that 4 moment directs the packet to San Francisco and then directly to Tokyo in only two hops. In such a case, the second packet may arrive in Tokyo before the first one routed through 6 a longer more circuitous path. This example highlights the problematic issue of using the 7 Internet for real-time communication such as live video streaming or VoIP, namely that 8 the Internet is not designed to guarantee the time of delivery or to control network delays 9 in performing the delivery. Latency can vary from 5Oms to over 1 second just depending on whether a packet is routed through only two servers or through fifteen. 11 The Internet's lack of routing control is problematic for real-time applications and 12 is especially an issue of poor QoS for OTT carriers - carriers trying to provide Internet 13 based telephony by catching a free ride on top of the Internet's infrastructure. Since the 14 OTT carrier doesn't control the routing, they can't control the delay or network latency. Another issue with packet-switched communication, is that it is easy to hijack data 16 without being detected. If a pirate intercepts a packet and identifies its source or 17 destination IP address, they can use a variety of methods to intercept data from 18 intervening routers and either sniff or redirect traffic through their own pirate network to 19 spy on the conversation and even crack encrypted files. The source and destination IP addresses and other important information used to 21 route a packet (and also used by pirates to hack a packet) are specified as a string of 22 digital data called an IP packet, IP datagram, or TCP/IP packet. The IP packet contains 23 digital information defining the physical connection between devices, the way the data is 24 organized to link the devices together, the network routing of the packet, a means to insure the useful data (payload) was delivered accurately and what kind of data is in the 26 payload, and then the payload data itself to be used by various application programs. 27 The IP packet is sent and received in sequence as a string of serial digital bits, 28 organized in a specific manner called the Internet Protocol as established by various 29 standards committees including the Internet Engineering Task Force or IETF among others. The standard insures that any IP packet following the prescribed protocol can 31 communicate with and be understood by any connected device complying with the same

1 IP standard. Insuring communication and interoperability of Internet connected devices 2 and applications are hallmarks of the Internet, and represent a guiding principal of the 3 Open Source Initiative or OSI, to prevent any company, government, or individual from 4 taking control of the Internet or limiting its accessibility or its functionality. The OSI model, an abstraction comprising seven layers of functionality, precisely 6 prescribes the format of an IP packet and what each segment of the packet is used for. 7 Each portion or "segment" of the IP packet corresponds to data applying to function of 8 the particular OSI layer 4. The roles of the seven OSI layers are as follows: 9 • Layer 1, the physical or PHY layer, comprises hardware specific information articulating the physical nature of communication as electrical, RF 11 and optical signals and the way those signals can be converted into bits for use in 12 the communicating system. Converting a specific communication medium such as 13 WiFi radio, Ethernet, serial ports, optical fiber, 3G or 4G cellular radio, DSL on 14 twisted pair copper wire, USB, Bluetooth, cable or satellite TV, or digital broadcasts of audio, video, or multimedia content into a bit stream is the task of 16 the PHY layer. In the IP packet, the preamble, represents Layer 1 data, and is used 17 to synchronize the entire data packet or "frame", to the hardware transceiving it. 18 • Layer 2, the data link layer, comprising bits arranged as frames, 19 defines the rules and means by which bit streams delivered from PHY Layer 1 are converted into interpretable data. For example, WiFi radio based bit streams may 21 comply with any number of IEEE defined standards including 802.11a, b, g, n, 22 and ac; 3G radio communication may be modulated using high-speed packet 23 access methods HSDPA or HSUPA; modulated light in an optical fiber or 24 electrical signals on a coaxial cable can be decoded into data in accordance with the DOCSIS 3 standard; etc. In the IP packet, Layer 2 data encapsulates its 26 payload into a datagram with a leading "data link header", and a trailing "data 27 link trailer", together defining when the encapsulated payload being delivered 28 starts and stops, as well as to insure nothing was lost in the transmission process. 29 One key element of Layer 2 data is the MAC or media access address, used to direct the data traffic to and from specific Ethernet addresses, RF links, or 31 hardware specific transceiver links.

1 • Layer 3, the network or Internet layer, comprises packets called 2 "datagrams" containing Internet Protocol (IP) information used for routing an IP 3 packet including whether the packet contains IPv4 or IPv6 data and the 4 corresponding source and destination IP addresses as well as information regarding the nature of the payload contained within the packet, i.e. whether the 6 type of transport protocol used comprises Transmission Control Protocol (TCP), 7 User Datagram Protocol (UDP) or something else. Layer 3 also includes a 8 function to prevent immortals - IP packets that are never delivered yet never die. 9 A specific type of Layer 3 packet, ICMP is used to diagnose the condition of a network, including the well-known "ping" function. In the IP packet, Layer 3 11 comprises "IP header" 82 and encapsulates its payload comprising transport and 12 upper layer segments. 13 • Layer 4, the transport layer, comprises segments of data defining 14 the nature of the connection between communicating devices, where UDP defines a minimal description of the payload for connectionless communication, namely 16 how large is the payload, were any bits lost, and what application service (port) 17 will use the delivered data. UDP is considered connectionless because it does not 18 confirm delivery of the payload, relying instead on the application to check for 19 errors or lost data. UDP is typically used for time sensitive communication such as broadcasting, multicasting, and streaming where resending a packet is not an 21 option. In contrast, TCP insures a virtual connection by confirming the packet and 22 payload are reliably delivered before the next packet is sent, and resends dropped 23 packets. TCP also checks the data integrity of the delivered packets using a 24 checksum, and includes provisions for reassembling out-of-sequence packets in their original order. Both TCP and UDP define the source and destination ports, a 26 description of an upper layer service or application, e.g. a web server or an email 27 server, concerned with the information contained within the Layer 4 payload. In 28 the IP packet, Layer 4 comprises the TCP / UDP header and encapsulates its data/ 29 payload comprising content used by upper OSI Layers 5, 6 and 7. • Layers 5, 6 and 7, the upper or application layers describe the 31 content delivered by the Internet as data / payload. Layer 7, the "application"

1 layer, represents the highest level in the OSI model and relies on the six 2 underlying OSI layers to support both open source and proprietary application 3 software. Commonly used Level 7 applications include email using SMTP, POP 4 or IMAP, web browsing using HTTP (Chrome, Safari, Explorer, Firefox), file transfers using FTP, and terminal emulation using Telnet. Proprietary applications 6 include the Microsoft Office suite of products (Word, Excel, PowerPoint), Adobe 7 Illustrator and Photoshop; Oracle and SAP database applications; Quicken, 8 Microsoft Money, and QuickBooks financial software; plus audio and video 9 players (such as iTunes, QuickTime, Real Media Player, Window Media Player, Flash), as well as document readers such Adobe Acrobat Reader and Apple 11 Preview. Level 7 applications generally also utilize embedded objects defined 12 syntactically by Level 6, the "presentation" layer, comprising text, graphics

& 13 pictures, sound and video, document presentations such as XML or PDF, along 14 with security functions such as encryption. Level 5, the "session" layer, establishes cross-application connectivity, such as importing one object into 16 another program file, and control initiating and terminating a session. 17 As described, the OSI seven-layer model defines the functions of each layer, and 18 the corresponding IP packet encapsulates data relating to each layer, one inside the other 19 in a manner analogous to the Babushka or Russian nesting doll, the wooden dolls with one doll inside another inside another and so on... The outer packet or Layer 1 PHY 21 defines the entire IP frame containing information relating to all the higher levels. Within 22 this PHY data, the Layer 2 data frame describes the data link layer and contains the Layer 23 3 network datagram. This datagram in turn describes the Internet layer as its payload, 24 with Layer 4 segment data describing the transport layer. The transport layer carries upper layer data as a payload including Layer 5, 6 and 7 content. The seven-layer 26 encapsulation is also sometimes referred to by the mnemonic "all people seem to need 27 data processing" ordering the seven OSI layers successively from top to bottom as 28 application, presentation, session, transport, network, data-link, and physical layers. 29 While the lower physical and link layers are hardware specific, the middle OSI layers encapsulated within the IP packet describing the network and transport information 31 are completely agnostic to the hardware used to communicate and deliver the IP packet.

1 Moreover, the upper layers encapsulated as the payload of the transport layer are specific 2 only to the applications to which they apply and operate completely independently from 3 how the packet was routed or delivered through the Internet. This partitioning enables 4 each layer to essentially be supervised independently, supporting a myriad of possible combinations of technologies and users without the need for managerial approval of 6 packet formatting or checking the viability of the packet's payload. Incomplete or 7 improper IP packets are simply discarded. In this manner, packet-switched networks are 8 able to route, transport and deliver diverse application related information over disparate 9 communication mediums in a coherent fashion between and among any Internet connected devices or objects. 11 In conclusion, switched circuit networks require a single direct connection 12 between two or more parties communicating (similar to the plain old telephone system of 13 a century ago), while packet switches network communication involves fragmenting 14 documents, sound, video, and text into multiple packets, and deliver those packets through multiple network paths (similar to the post office using best efforts to provide 16 delivery in an accurate and timely manner), then reassembling the original content and 17 confirming nothing was lost along the way. A comparison between circuit-switched 18 PSTNs versus packet-switched VoIP is summarized in the following table: 19 Netw\ork PSTN In1terniet Technology Circuit-switched Packet-switched

Connection Dedicated electrical Each packet routed over Internet connection Data delivery Real-time (circuit) Best effort (packet) Signal Analog or digital Digital, IP, VoIP Content Voice Voice, text, data, video Data Rate Low High Error Checking None, or minimal Extensive Effect of Broken Line Broken or cropped call Call rerouted

Effect of Power Failure Network delivers power Battery backup required

1 It should be mentioned here that while PSTNs operate using real-time electrical 2 circuit connections, packet-switched networks deliver content using "best effort" methods 3 to find a way to deliver a packet and payload, not unlike the post office using different 4 trucks and letter carriers to eventually deliver the mail, even if its late to arrive. Operation of packet switched networks and communication is explained in greater detail in the 6 background section of a related patent application entitled "Secure Dynamic 7 Communication Network and Protocol," of which this disclosure is a Continuation in 8 Part. 9 When considering the performance of a network, several factors are considered namely, 11 • Data rate, i.e. bandwidth 12 • Quality of service 13 • Network and data security 14 • User privacy Of the above considerations, data rates are easily quantified in millions of bits per 16 second or Mbps. Quality of Service or QoS, on the other the other hand, includes several 17 factors including latency, sound quality, network stability, intermittent operation or 18 frequent service interruptions, synchronization or connection failures, low signal strength, 19 stalled applications, and functional network redundancy during emergency conditions. Cybersecurity and cyberprivacy deals with preventing attacks on the network and 21 thwarting unauthorized access to data traffic and contents, including cybercrime, 22 cybersurveillance, IP packet sniffing, port interrogation and denial of service attacks, 23 profiling, imposters, packet hijacking, cyber-infections, surveillance, pirate 24 administration & infiltration

26 Quality of Service 27 Quality of Service describes the performance of the network in capacity, 28 bandwidth, latency, data rate, scalability, sound quality data integrity, data bit error rates, 29 and other performance based parameters. For programs, files, and security related verifications, data accuracy is a critical factor. Which factors are important depends on 31 the nature of the payload being carried across a packet-switched network. In contrast, for

1 voice and video comprising real-time applications, factors affecting packet delivery time 2 are key. Quality factors and how they affect various applications such as video, voice, 3 data, and text vary depending on the application. A good network condition typified by 4 consistent high data rate IP packet waveform is one where there are minimal time delays, clear strong signal strength, no signal distortion, stable operation, and no packet 6 transmission loss. 7 Intermittent networks with lower data rate packet waveforms suffer occasional 8 intermittencies affect video functions most significantly, causing painfully slow video 9 downloads and making video streaming unacceptable. Congested networks operating a lower effective data throughput rates with regular short duration interruptions 11 exemplified by IP packet waveform not only severely degrade video with jerky 12 intermittent motion, fuzzy pictures, and improper coloring and brightness, but also begin 13 to degrade sound or vocal communication with distortion, echo, and even whole 14 sentences dropped from a conversation or soundtrack. In congested networks, however, data can still be delivered using TCP by repeated requests for rebroadcasts. In the 16 extreme, unstable networks exhibit low data throughput rates with numerous data 17 stoppages of unpredictable durations. Unstable networks also include corrupted IP 18 packages as represented by the darkly shaded packets in waveform 610D, which in TCP 19 based transport must be resent and in UDP transport are simply discarded as corrupt or improper data. At some level of network degradation even emails become intermittent 21 and MAP fie synchronization fails. Because of their lightweight data format, most SMS 22 and text messages will be delivered, albeit with some delivery delay, even with severe 23 network congestion but attachments will fail to download. In unstable networks every 24 application will fail and can even result in freezing a computer or cellphone's normal operation waiting for an expected file to be delivered. In such cases video freezes, sound 26 become so choppy it becomes unintelligible, VoIP connections drop repeatedly even over 27 a dozen times within a few minute call, and in some cases fails to connect altogether. 28 Likewise, emails stall or freeze with computer icons spinning round and round 29 interminably. Progress bars halt altogether. Even text messages bounce and "undeliverable".

1 While many factors can contribute to network instability, including power failures 2 on key servers and super POPs, overloaded call volumes, the transmission of huge data 3 files or UHD movies, and during significant denial of service attacks on select servers or 4 networks, the key factors used to track a network's QoS are its packet drop rate and packet latency. Dropped packets occur when an IP packet cannot be delivered and "times 6 out" as an immortal, or where a router or server detects a checksum error in the IP 7 packet's header. If the packet using UDP, the packet is lost and the Layer 7 application 8 must be smart enough to know something was lost. If TCP is used for Layer 4 transport, 9 the packet will be requested for retransmission, further adding loading to a potentially already overloaded network. 11 The other factor determining QoS, propagation delay, may be measured 12 quantitatively in several ways, either as an IP packet's delay from node-to-node, or 13 unidirectionally from source to destination, or alternatively as the round-trip delay from 14 source to destination and back to the source. The effects of propagation delay on packet delivery differ using UDP and TCP transport protocols. As the intermodal network 16 propagation delay increases, the time needed to perform round-trip communication such 17 as in VoIP conversation increases. In the case of UDP transport, the round trip delay 18 increases linearly with propagation delay. Since long propagation delays correlate to 19 higher bit error rates, the number of lost UDP packets increases, but because UDP does request the resending of dropped packets, the round trip time remains linear with 21 increased delay. TCP transport exhibits a substantially longer round trip time for each 22 packet sent than UDP because of the handshaking required confirming packet delivery. If 23 the bit error rate remains low and most packets do not require resending then TCP 24 propagation delay increases linearly with intermodal propagation delay. If, however, the communication network becomes unstable as the propagation delay increases, then the 26 round trip time resulting from TCP transport grows exponentially because of the 27 protocol's need for retransmission of dropped packets. As such, TCP is contraindicated 28 for time sensitive applications such as VoIP and video streaming. 29 Since all packet communication is statistical, with no two packets having the same propagation time, the best way to estimate the single direction latency of a network 31 is by measuring the round trip time of a large number of similarly sized IP packets and

1 dividing by two to estimate the single-direction latency. Latencies under 1OOms are 2 outstanding, up to 200ms are considered very good, and up to 300ms still considered 3 acceptable. For propagation delays of 500ms, easily encountered by OTT applications 4 running on the Internet, the delays become uncomfortable to users and interfere which normal conversation. In voice communication, in particular such long propagation delays 6 sound "bad" and can result in reverberation, creating a "twangy" or metallic sounding 7 audio, interrupting normal conversation while the other party waits to get your response 8 to their last comment, and possibly resulting in garbled or unintelligible speech. 9 To be clear, the single-direction latency of a communication is different than the ping test performed by the Layer 3 ICMP utility (such as the free network test at 11 http://www.speedtest.net) in part because ICMP packets are generally lightweight 12 compared to real IP packets, because the ping test does not employ the "request to 13 resend" feature of TCP, and because there is no guarantee over a public network of the 14 Internet, that the ping test's route will match the actual packet route. In essence, when the ping experiences a long delay, something is wrong with the network or some link 16 between the device and the network, e.g. in the WiFi router, or the last mile, but a good 17 ping result by itself cannot guarantee low propagation delay of a real packet. 18 In order to improve network security, encryption and verification methods are 19 often employed to prevent hacking, sniffing or spying. But heavy encryption and multiple key encryption protocols constantly reconfirming the identity of a conversing parties, 21 create additional delays and in so doing increase the effective network latency, degrading 22 QoS at the expense of improving security. 23 24 Cybersecurity and Cyberprivacy The other two major considerations in communications are that of cybersecurity 26 cyberprivacy. While related, the two issues are somewhat different. "Cybersecurity 27 including network security, computer security and secure communications, comprises 28 methods employed to monitor, intercept, and prevent unauthorized access, misuse, 29 modification, or denial of a computer or communications network, network-accessible resources, or the data contained within network connected devices. Such data may 31 include personal information, biometric data, financial records, health records, private

1 communications and recordings, as well as private photographic images and video 2 recordings. Network-connected devices include cell phones, tablets, notebooks, desktops, 3 file servers, email servers, web servers, data bases, personal data storage, cloud storage, 4 Internet-connected appliances, connected cars, as well as publically shared devices used by an individual such as point-of-sale or POS terminals, gas pumps, ATMs, etc. 6 Clearly, cybercriminals and computer hackers who attempt to gain unauthorized 7 access to secure information are committing a crime. Should illegally obtained data 8 contain personal private information, the attack is also a violation of the victim's personal 9 privacy. Conversely, however, privacy violations may occur without the need for cybercrime and may in fact be unstoppable. In today's network-connected world, 11 unauthorized use of a person's private information may occur without the need of a 12 security breach. In many cases, companies collecting data for one purpose may choose to 13 sell their data base to other clients interested in using the data for another purpose 14 altogether. Even when Microsoft purchased Hotmail, it was well known that the mail list was sold to advertisers interested in spamming potential clients. Whether such actions 16 should be considered a violation of cyberprivacy remains a matter of opinion. 17 "Cyberprivacy" including Internet privacy, computer privacy, and private 18 communication involves an individual's personal right or mandate to control their 19 personal and private information and its use, including the collection, storage, displaying or sharing of information with others. Private information may involve personal identity 21 information including height, weight, age, fingerprints, blood type, driver's license 22 number, passport number, social-security number, or any personal information useful to 23 identify an individual even without knowing their name. In the future, even an 24 individual's DNA map may become a matter of legal record. Aside from personal identifying information, non-personal private information may include what brands of 26 clothes we buy, what web sites we frequent, whether we smoke, drink, or own a gun, 27 what kind of car we drive, what diseases we may have contracted in our life, whether our 28 family has a history of certain diseases or ailments, and even what kind of people we are 29 attracted to. This private information, when combined with public records relating to personal 31 income, taxes, property deeds, criminal records, traffic violations, and any information

1 posted on social media sites, forms a powerful data set for interested parties. The 2 intentional collection of large data sets capturing demographic, personal, financial, 3 biomedical, and behavioral information and mining the data for patterns, trends and 4 statistical correlations today is known as "big data". The healthcare industry, including insurance companies, healthcare providers, pharmaceutical companies, and even 6 malpractice lawyers, are all intensely interested in personal information stored as big 7 data. Automotive and consumer products companies likewise want access to such 8 databases in order to direct their market strategy and advertising budgets. In recent 9 elections, even politicians have begun to look to big data to better understand voters' opinions and points of political controversy to avoid. 11 The question of cyberprivacy is not whether big data today captures personal 12 information (it's already standard procedure), but whether the data set retains your name 13 or sufficient personal identity information to identify you even in the absence of knowing 14 your name. For example, originally, the U.S. government stated that the personal information gathered by the healthcare.gov web site used for signing up to the Affordable 16 Care Act would be destroyed once the private medical accounts were set up. Then, in a 17 recent revelation, it was disclosed that a third-party corporation facilitating the data 18 collection for the U.S. government had previously signed a government contract 19 awarding it the right to retain and use the data it collected, meaning that personal private data divulged to the U.S. government is in fact not private. 21 As a final point, it should be mentioned that surveillance is practiced both by 22 governments and by crime syndicates using similar technological methods. While the 23 criminals clearly have no legal right to gather such data, the case of unauthorized 24 government surveillance is murkier, varying dramatically from country to country. The United States NSA for example has repeatedly applied pressure on Apple, Google, 26 Microsoft and others to provide access to their clouds and databases. Even government 27 officials have had their conversations and communiques wiretapped and intercepted. 28 When asked if Skype, a division of Microsoft, monitors the content of its callers, the 29 Skype Chief Information Officer abruptly replied "no comment."

1 Methods of Cybercrime & Cybersurveillance - Focusing on the topic of 2 cybersecurity, numerous means exist to gain unauthorized access to device, network and 3 computer data, including a variety of malware and hacker technologies used to commit 4 cybercrime and achieve unauthorized intrusions into allegedly secure networks. For example, an individual using a tablet connected to the Internet may wish to 6 place a call to a business office phone, send a message to a TV, call a friend in the 7 country still using a circuit switched POTS network, download files from web storage, or 8 send emails through email server. While all of the applications represent normal 9 applications of the Internet and global interconnectivity, many opportunities for surveillance, cybercrime, fraud, and identity theft exist through the entire network. 11 For example, for a tablet connecting to the network through a cellular radio 12 antenna and LTE cellular base station or through short-range radio antenna and public 13 WiFi base station, an unauthorized intruder can monitor the radio link. Likewise LTE 14 calls over cellular link can be monitored or "sniffed" by an intercepting radio receiver or sniffer. The same sniffer can be adjusted to monitor WiFi links and on the receiving end 16 on cable between the cable CMTS and cable modem. 17 In some instances, the LTE call can also be intercepted by a pirate faux-tower, 18 establishing a diverted communication path between a tablet and cellular tower. 19 Communications sent through the packet-switched network to a router, server, server, and cloud storage are also subject to man in the middle attacks. Wiretaps can intercept calls 21 on the POTS line from PSTN gateway to phones and also on a corporate PBX line 22 between PBX servers and office phones. 23 Through a series of security breaches, spyware can install itself onto a tablet or 24 notebook, on a router, on a PSTN-bridge, on cloud storage,, on a cable CMTS, or on a desktop computer. Trojan horse software may install itself on a tablet or desktop to phish 26 for passwords. A worm may also be used to attack a desktop, especially if the computer 27 runs Microsoft operating system with active X capability enabled. Finally, to launch 28 denial of service attacks, a virus can attack any number of network-connected devices 29 including servers, desktops, and tablets. Malware may therefore operate on differing portions of the communication 31 network and infrastructure, where cyber-assaults may include viruses, man in the middle

1 attacks government surveillance, and denial of service attacks. The last mile of the 2 communication network offers an even more extensive opportunity for malware and 3 cyber-assaults, divided into three sections, the local telco/network, the last link, and the 4 device. The local telco/network as shown comprises high-speed wired or fiber links, routers, cable CMTS,, cable/fiber, cable modems, WiFi antennas, and LTE radio 6 networks. In this portion of the network radio sniffers, spyware, viruses, and man in the 7 middle attacks are all possible. 8 In the last link, the local connection to the device, the network connection 9 comprises wireline connections, WiFi links, and LTE / radio cellular links subject to spyware, radio sniffers, wiretaps, and faux towers. The device itself, including for 11 example tablets, notebooks, desktops smartphones, smart TVs, POS terminals, etc. are 12 subject to a number of attacks including spyware, Trojan horses, viruses, and worms. 13 Such surveillance methods and spy devices are readily available in the commercial and 14 online marketplace, including devices used for monitoring traffic on Ethernet local area networks, devices for monitoring WiFi data, and for surveillance of cellular 16 communications. While sniffing of optical fiber cloud connections was initially not 17 considered as a threat, recently non-invasive data sniffers for optical communications 18 have emerged, i.e. one where the fiber need not be cut or its normal operation impaired 19 even temporarily, now exists. Aside from using hacking and surveillance methods, a wide variety of commercial 21 spyware is readily available for monitoring cell phone conversations and Internet 22 communications. Today, commercially available spyware programs advertise a number 23 of features such as the ability to beneficially spy on your employees, your kids, and your 24 spouse. The feature set is surprisingly comprehensive including spying on calls, photos and videos, SMS/MMS texting, third party instant messaging, emails, GPS location 26 tracking, Internet use, address book, calendar events, bugging, control apps, and even 27 remote control features, together comprising a frighteningly convincing number of a 28 ways to violate cyberprivacy. In fact cyber-assaults have now become so frequent, they 29 are tracked on a daily basis. To launch a cyber-assault generally involves several stages or combination of 31 techniques, including:

1 • IP packet sniffing 2 • Port interrogation 3 • Profiling 4 • Imposters • Packet-hijacking 6 • Cyber-infections 7 • Surveillance 8 • Pirate administration 9 IPPacket Sniffing - Using radio-monitoring devices, a cybercriminal can gain 11 significant information about a user, their transactions, and their accounts. In packet 12 sniffing, the contents of an IP packet can be obtained or "sniffed" anywhere in the path 13 between two users. For example, when a user sends a file, e.g. a photo or text, in an IP 14 packet from their notebook to the cell phone of their friend, a cyber-pirate can discover the IP packet in any number of places, either by intercepting the sender's last link, the 16 intercepting the sender's local network, monitoring the cloud, intercepting the receiver's 17 local telco, or by intercepting the receiver's last link. The observable data contained in 18 intercepted IP packet includes the Layer-2 MAC addresses of the devices used in the 19 communication, the Layer-3 addresses of the sender of the receiving party, i.e. the packet's destination, including the transport protocol, e.g. UDP, TCP, etc. being used. 21 The IP packet also contains, the Layer-4 port number of the sending and receiving 22 devices potentially defining the type of service being requested, and the data file itself If 23 the file is unencrypted, the data contained in the file can also be read directly by a cyber 24 pirate. If the payload is unencrypted, textual information such as account numbers, login 26 sequences, and passwords can be read and, if valuable, stolen and perverted for criminal 27 purposes. If the payload contains video or pictographic information, some added work is 28 required to determine which Layer 6 application-format the content employs, but once 29 identified the content can be viewed, posted publically, or possibly used for blackmailing one or both of the communicating parties. Such cyber-assaults are referred to as a "man

1 in the middle attack" because the cyber-pirate doesn't personally know either 2 communicating party. 3 As described previously, since IP packet routing in the cloud is unpredictable, 4 monitoring the cloud is more difficult because a cyber-pirate must capture and the IP packet's important information when it first encounters it, because subsequent packets 6 may not follow the same route and the sniffed packet. Intercepting data in the last mile 7 has a greater probability to observe a succession of related packets comprising the same 8 conversation, because local routers normally follow a prescribed routing table, at least 9 until packets reach a POP outside the customer's own carrier. For example, a client of Comcast will likely pass IP packets up the routing chain using an entirely Comcast 11 owned network till the packet moves geographically beyond Comcast's reach and 12 customer service region. 13 If a succession of packets between the same two IP addresses occurs for a 14 sufficiently long time, an entire conversation can be recreated piecemeal. For example, if SMS text messages are passed over the same network in the last mile, a cyber-pirate can 16 identify through the IP addresses and port #s that multiple IP packets carrying the text 17 represent a conversation between the same two devices, i.e. a cell phone and notebook. 18 So even if an account number and password were texted in different messages or sent 19 incompletely spread over many packets, the consistency of the packet identifiers still makes it possible for a cyber pirate to reassemble the conversation and steal the account 21 info. Once the account info is stolen, they can either transfer money to an offshore bank 22 or even usurp the account authority by changing the account password and security 23 questions, i.e. using identity theft on a temporary basis. 24 Even if the payload is encrypted, the rest of IP packet including the IP addresses and port #s are not. After repeatedly sniffing a large number of IP packets, a cyber pirate 26 with access to sufficient computing power can by shear brute force, systematically try 27 every combination until they break the encryption password. Once the key is broken, the 28 packet and all subsequent packets can be decrypted and used by a cyber-pirate. The 29 probability of cracking a login password by "password guessing" greatly improves if the packet sniffing is combined with user and account "profiling" described below. Notice in

1 "man in the middle attacks" the communicating devices are not normally involved 2 because the cyber pirate does not have direct access to them. 3 4 Port Interrogation - Another method to break into a device is to use its IP address to interrogate many Layer-4 ports and see if any requests receive a reply. Once a 6 cyber-pirate identifies from packet sniffing or other means the IP address of a targeted 7 device, the cyber-pirate can launch a sequence of interrogations to ports on the device 8 looking for any unsecure or open port, service and maintenance port, or application 9 backdoor. While a hacker's interrogation program can systematically cycle through every port #,attacks generally focus on notoriously vulnerable ports such as port # 7 for ping, 11 port #21 for FTP, port # 23 for telnet terminal emulation, port # 25 for simple email, and 12 so on. Every time a pirate sends packets, to which the device responds, the pirate learns 13 something more about the operating system of the targeted device. 14 In the port interrogation process, a cyber pirate doesn't want to expose their real identity so they will use a disguised pseudo-address to receive messages but that is not 16 traceable to them personally. Alternatively, cybercriminals may use a stolen computer 17 and account, so it looks like someone else is trying to hack the targeted device, and if 18 traced, leads investigators back to an innocent person and not to them. 19 Profiling - User and account profiling is the process where a cyber pirate performs research using publically available information to learn about a target, their 21 accounts, and their personal history in order to crack passwords, identify accounts, and 22 determine assets. Once a hacker obtains the IP address of a target using sniffing or other 23 means, the traceroute utility can be used to find the DNS server of the device's account. 24 Then by utilizing the "Who is" function on the Internet, the name of the account owner can be discovered. In profiling, a cybercriminal then searches on the Internet to gather all 26 available information on the account owner. Sources of information include public 27 records such as property deeds, car registration, marriages and divorces, tax liens, parking 28 tickets, traffic violations, criminal records, etc. In many cases, web sites from universities 29 and professional societies also include home address, email addresses, phone numbers and an individual's birthdate. By researching social media sites such as Facebook, Linked 31 In, Twitter, and others, a cybercriminal can amass a significant detailed information

1 including family and friends, pets' names, previous home addresses, classmates, major 2 events in someone's life, as well as photographic and video files, including embarrassing 3 events, family secrets, and personal enemies. 4 The cyber pirate's next step is to use this profile to "guess" a user's passwords based on their profile to hack the target device and other accounts of the same individual. 6 Once a cybercriminal cracks one device's password, the likelihood is great they can break 7 into other accounts because people tend to reuse their passwords for ease of memorizing. 8 At that point, it may be possible to steal a person's identity, transfer money, make them a 9 target of police investigations, and essentially destroy someone's life while stealing all their wealth. For example, as described in the opening section of this disclosure, 11 amassing a long list of passwords from stolen accounts, cybercriminals used the same 12 passwords to illegally purchase millions of dollars of premium tickets to concerts and 13 sporting events using the same passwords and login information. 14 Imposters - When a cyber pirate impersonates someone they are not or uses 16 illegally obtained cyber-security credentials to gain access to communication and files 17 under the false pretense of being an authorized agent or device, the cyber-pirate is acting 18 as an "imposter". The imposter type of cyber-assault can occur when a cybercriminal has 19 sufficient information or access to an individual's account to usurp a victim's account, sending messages on their behalf and misrepresenting them as the owner of the hacked 21 account. Recently, for example, a personal friend of one of the inventors had her "Line" 22 personal messenger account hacked. After taking over the account, the cybercriminal sent 23 messages to her friends misrepresenting that "she had a car accident and needed money 24 as an emergency loan", including providing wiring instructions for where to send the money. Not knowing the account had been hacked her friends thought the request was 26 real and rushed to her financial rescue. To avoid suspicion, the request sent to each friend 27 was under $1,000 USD. Fortunately just before wiring money, one of her friends called 28 her to double check the wiring info, and the fraud was uncovered. Without calling, no one 29 would have never known the requests were from an imposter and the Line account owner would never have known the wire had been sent or even requested.

1 Another form of misrepresentation occurs when a device has granted security 2 privileges and is enabled to exchange information with a server or other network 3 connected device, and by some means a cyber-pirate device disguises itself as the 4 authorized server, whereby the victim's device willingly surrenders files and information to the pirate server not realizing the server is an imposter. This method was reportedly 6 used to lure celebrities to backup private picture files with iCloud, except that the backup 7 cloud was an imposter. 8 Another form of imposter occurs when someone with physical access to a 9 person's phone or open browser performs an imposter transaction such as sending an email, answering a phone call, sending a text message from another person's account or 11 device. The receiving party assumes because they are connected to a known device or 12 account, that the person operating that device or account is its owner. The imposter can 13 be a prank such as a friend posting embarrassing comments of Facebook or can be of a 14 more personal nature where someone's spouse answers personal calls or intercepts private text messages of a private nature. The result of the unauthorized access can lead 16 to jealousy, divorce, and vindictive legal proceedings. Leaving a device temporarily 17 unsupervised in an office or cafe, e.g. to run to the toilet, presents another risk for an 18 imposter to quickly access personal or corporate information, send unauthorized emails, 19 transfer files, or download some form of malware into the device, as described in the following section entitled "infections". 21 Imposter-based cyber-assault is also significant when a device is stolen. In such 22 events, even though the device is logged out, the thief has plenty of time in which to 23 break the login code. The "find my computer" feature that is supposed to locate the stolen 24 device on the network and wipe a computer's files the first time the cyber pirate logs on to the device, no longer works because tech-savvy criminals today know to activate the 26 device only where there is no cellular or WiFi connection. This risk is especially great in 27 the case of cell phones where the passline security is a simple four-number personal 28 identification number or PIN. It's only a matter of time to break a PIN since there are 29 only 9999 possible combinations. The key issue to secure any device is to prevent access to imposters. Preventing 31 imposters requires a robust means to authenticate a user's identity at regular intervals and

1 to insure they are only authorized to access the information and privileges they need. 2 Device security is oftentimes the weakest link in the chain. Once a device's security is 3 defeated, the need for robust network security is moot. 4 Packet Hijacking - Packet hijacking comprises a cyber-assault where the normal 6 flow of packets through the network is diverted through a hostile device. 7 If for example, the integrity of a router is compromised by a cyber-assault from a 8 cyber-pirate, IP packets traversing the router can be rewritten into a revised IP packet, 9 diverting the IP package to a different destination address and port # of the cyber-pirate device. The cyber-pirate device then obtains whatever information it needs from the 11 payload of the IP packet and possibly changes the content of the IP packet's payload. The 12 fraudulent payload may be used to commit any number of fraudulent crimes, to gather 13 information, or to download malware into the cell phone, described subsequently herein 14 under the topic "infections". The hijacked packet, is then retrofitted to appear like the original IP packet's 16 source IP address and source port #, except that the packet travels through a new and 17 different path. Alternatively the hijacked IP packet can be returned to the compromised 18 router and then sent on to the cloud as before. In order to maximize the criminal benefit 19 of packet hijacking, a cyber pirate needs to hide their identity in the packet hijacking, and for that reason they disguise the true routing of the IP packet so even the Layer-3 ICMP 21 function "traceroute" would have difficulty in identifying the true path of the 22 communication. If, however, the hijacking adds noticeable delay in packet routing, the 23 unusual latency may prompt investigation by a network operator. 24 Cyber-infections - One of the most insidious categories of cyber-assault is that of 26 "cyber-infections", installing malware into targeted devices or the network by which to 27 gather information, commit fraud, redirect traffic, infect other devices, impair or shut 28 down systems, or to cause denial of service failures. Cyber infections can be spread 29 through emails, files, web sites, system extensions, application programs, or through networks. One general class of malware, "spyware" gathers all kinds of transactional 31 information and passes it on to a cyber pirate. In the case of "phishing", a wen page or an

1 application shell that appears like a familiar login page asks for account login or personal 2 information then forwards the information to a cyber pirate. Still other malware 3 infections can take control of hardware, e.g. control a router to execute the 4 aforementioned packet hijacking. In these cases, the cyber pirate is attempting to gain information or control beneficially for their own purposes. 6 Another class of cyber-infections comprising viruses, worms, and Trojan-horses 7 is designed to overwrite critical files, or to execute meaningless functions repeatedly to 8 prevent a device from doing its normal tasks. Basically to deny services, degrade 9 performance, or completely kill a device. These malevolent infections are intrinsically destructive and used for vindictive purposes, to disable a competitor's business from 11 normal operation, or simply motivated for fun by a hacker wanting to see if it's possible. 12 13 Surveillance - Bugging and surveillance goes beyond cybercrime. In such 14 instances a private detective or an acquaintance is hired or coerced to installing a device or program into the target's personal devices to monitor their voice conversations, data 16 exchanges, and location. The risk of being caught is greater because the detective must 17 gain temporary access to the target device without the subject knowing it. For example, 18 STMcards are commercially available that can copy a phone's network access privileges 19 but concurrently transmit information to a cybercriminal monitoring the target's calls and data traffic. 21 Other forms of surveillance involve the use of clandestine video cameras to 22 monitor a person's every action and phone call, much as those located in casinos. 23 Through video monitoring, a device's password or PIN can be learned simply by 24 observing a user's keystrokes during their login process. With enough cameras in place, eventually once will record the login process. To access a camera network without raising 26 suspicion, a cyber pirate can hack an existing camera surveillance system on buildings, in 27 stores, or on the streets, and through access to someone's else's network monitor the 28 behavior of unsuspecting victims. Combining video surveillance with packet sniffing 29 provides an even more comprehensive data set for subsequently launching cyber-assaults.

1 Pirate Administration (Infiltration) - One other means by which cyber pirates 2 are able to gain information is by hacking and gaining access to system administration 3 rights of a device, server, or network. So rather than gaining unauthorized access to one 4 user's account, by hacking the system administrator's login, significant access and privileges become available to the cyber pirate without the knowledge of those using the 6 system. Since the system administrator acts as a system's police, there is no one to catch 7 their criminal activity - in essence; in a system or network with corrupted administration 8 there is no one able to police the police. 9 Conclusion - The ubiquity and interoperability that the Internet, packet-switched 11 networks, and the nearly universal adoption of the seven-layer open source initiative 12 network model, has over the last twenty years enabled global communication to expand 13 on an unparalleled scale, connecting a wide range of devices ranging from smartphone to 14 tablets, computers, smart TVs, cars and even to home appliances and light bulbs. The global adoption of the Internet Protocol or IP as the basis for Ethernet, cellular, WiFi, and 16 cable TV connectivity not only has unified communication, but has greatly simplified the 17 challenge for hackers and cybercriminals attempting to invade as many devices and 18 systems as possible. Given the plethora of software and hardware methods now available 19 to attack today's communication networks, clearly no single security method is sufficient as a sole defense. Instead what is needed is a systematic approach to secure every device, 21 last-link, local telco/network and cloud network to insure their protection against 22 sophisticated cyber-assaults. The methods utilized should deliver intrinsic cybersecurity 23 and cyberprivacy without sacrificing QoS, network latency, video or sound quality. 24 While encryption should remain an important element of developing this next generation in secure communication and data storage, the network's security must not rely solely on 26 encryption methodologies. 27 28 Summary of the Invention 29 In accordance with this invention, data (which is defined broadly to include text, audio, video, graphical, and all other kinds of digital information or files) is transmitted 31 over a Secure Dynamic Communication Network and Protocol (SDNP) network or

1 "cloud." The SDNP cloud includes a plurality of "nodes," sometimes referred to as 2 "media nodes," that are individually hosted on servers or other types of computers or 3 digital equipment (collectively referred to herein as "servers") located anywhere in the 4 world. It is possible for two or more nodes to be located on a single server. Typically, the data is transmitted between the media nodes by light carried over fiber optic cables, by 6 radio waves in the radio or microwave spectrum, by electrical signals conducted on 7 copper wires or coaxial cable, or by satellite communication, but the invention broadly 8 includes any means by which digital data can be transmitted from one point to another. 9 The SDNP network includes the SDNP cloud as well as the "Last Mile" links between the SDNP cloud and client devices such as cell phones, tablets, notebook and desktop 11 computers, mobile consumer electronic devices, as well as Internet-of-Things devices and 12 appliances, automobiles and other vehicles. Last Mile communication also includes cell 13 phone towers, cable or fiber into the home, and public WiFi routers. Within the Last 14 Mile, the link between the client device and the nearest cell phone tower or other re transmitter is referred to as the "Last Link." 16 While in transit between the media nodes in the SDNP cloud, the data is in the 17 form of "packets," discrete strings of digital bits that may be of fixed or variable length, 18 and the data is disguised by employing the following techniques: scrambling, encryption 19 or splitting-or their inverse processes, unscrambling, decryption and mixing. (Note: As used herein, unless the context indicates otherwise, the word "or" is used in its 21 conjunctive (and/or) sense.) 22 Scrambling entails reordering the data within a data packet; for example, data 23 segments A, B and C which appear in that order in the packet are re-ordered into the 24 sequence C, A and B. The reverse of the scrambling operation is referred to as "unscrambling" and entails rearranging the data within a packet to the order in which it 26 originally appeared - A, B and C in the above example. The combined operation of 27 unscrambling and then scrambling a data packet is referred to as "re-scrambling." In re 28 scrambling a packet that was previously scrambled, the packet may be scrambled in a 29 manner that is the same as, or different from, the prior scrambling operation. The second operation, "encryption," is the encoding of the data in a packet into a 31 form, called ciphertext, that can be understood only by the sender and other authorized

1 parties, and who must perform the inverse operation - "decryption" - in order to do so. 2 The combined operation of decrypting a ciphertext data packet and then encrypting it 3 again, typically but not necessarily using a method that is different from the method used 4 in encrypting it previously, is referred to herein as "re-encryption." The third operation, "splitting," as the name implies, involves splitting up the 6 packet into two or more smaller packets. The inverse operation, "mixing," is defined as 7 recombining two or more packets into a single packet. Splitting a packet that was 8 previously split and then mixed may be done in a manner that is the same as, or different 9 from, the prior splitting operation. The order of operations is reversible, whereby splitting may be undone by mixing and conversely mixing of multiple inputs into one output may 11 be undone by splitting to recover the constituent components. (Note: Since scrambling 12 and unscrambling, encryption and decryption, and splitting and mixing are inverse 13 processes, knowledge of the algorithm or method that was used to perform one is all that 14 is necessary to perform the inverse. Hence, when referring to a particular scrambling, encryption, or splitting algorithm herein, it will be understood that knowledge of that 16 algorithm allows one to perform the inverse process.) 17 In accordance with the invention, a data packet that passes through an SDNP 18 cloud is scrambled or encrypted, or it is subjected to either or both of these operations in 19 combination with splitting. In addition, "junk" (i.e., meaningless) data may be added to the packet either to make the packet more difficult to decipher or to make the packet 21 conform to a required length. Moreover, the packet may be parsed, i.e., separated into 22 distinct pieces. In the computing vernacular, to parse is to divide a computer language 23 statement, computer instruction, or data file into parts that can be made useful for the 24 computer. Parsing may also be used to obscure the purpose of an instruction or data packet, or to arrange data into data packets having specified data lengths. 26 Although the format of the data packets follows the Internet Protocol, within the 27 SDNP cloud, the addresses of the media nodes are not standard Internet addresses, i.e. 28 they cannot be identified by any Internet DNS server. Hence, although the media nodes 29 can technically receive data packets over the Internet, the media nodes will not recognize the addresses or respond to inquiries. Moreover, even if Internet users were to contact a 31 media node, they could not access or examine the data inside the media node because the

1 media node can recognize them as imposters lacking the necessary identifying credentials 2 as a SDNP media node. Specifically, unless a media node is registered as a valid SDNP 3 node running on a qualified server in the SDNP name server or its equivalent function, 4 data packets sent from that node to other SDNP media nodes will be ignored and discarded. In a similar manner. only clients registered on an SDNP name server may 6 contact a SDNP media node. Like unregistered servers, data packets received from 7 sources other than registered SDNP clients will be ignored and immediately discarded. 8 In a relatively simple embodiment, referred to as "single route," the data packet 9 traverses a single path through a series of media nodes in the SDNP cloud, and it is scrambled at the media node where it enters the cloud and unscrambled at the media node 11 where the packet exits the cloud (these two nodes being referred to as "gateway nodes" or 12 "gateway media nodes"). In a slightly more complex embodiment, the packet is re 13 scrambled at each media node using a scrambling method different from the one that was 14 used at the prior media node. In other embodiments, the packet is also encrypted at the gateway node where it enters the cloud and decrypted at the gateway node where it exits 16 the cloud, and in addition the packet may be re-encrypted at each media node it passes 17 through in the cloud. Since a given node uses the same algorithm each time it scrambles 18 or encrypts a packet, this embodiment is describes as "static" scrambling and encryption. 19 In a case where the packet is subjected to two or more operations, e.g., it is scrambled and encrypted, the inverse operations are preferably performed in an order 21 opposite to the operations themselves, i.e. in reverse sequence. For example, if the packet 22 is scrambled and then encrypted prior to leaving a media node, it is first decrypted and 23 then unscrambled when it arrives at the following media node. The packet is recreated in 24 its original form only while it is within a media node. While the packet is in transit between media nodes, it is scrambled, split or mixed, or encrypted. 26 In another embodiment, referred to as "multiroute" data transport, the packet is 27 split at the gateway node, and the resulting multiple packets traverse the cloud in a series 28 of "parallel" paths, with none of the paths sharing a media node with another path except 29 at the gateway nodes. The multiple packets are then mixed to recreate the original packet, normally at the exit gateway mode. Thus, even if a hacker were able to understand the 31 meaning of a single packet, they would have only a part of the entire message. The packet

1 may also be scrambled and encrypted at the gateway node, either before or after it is split, 2 and the multiple packets may be re-scrambled or re-encrypted at each media node they 3 pass through. 4 In yet another embodiment, the packets do not travel over only a single path or a series of parallel paths in the SDNP cloud, but rather the packets may travel over a wide 6 variety of paths, many of which intersect with each other. Since in this embodiment a 7 picture of the possible paths resembles a mesh, this is referred to as "meshed transport." 8 As with the embodiments described above, the packets may be scrambled, encrypted and 9 split or mixed as they pass through the individual media nodes in the SDNP cloud. The routes of the packets through the SDNP network are determined by a 11 signaling function, which can be performed either by segments of the media nodes 12 themselves or preferably, in "dual-channel" or "tri-channel" embodiments, by separate 13 signaling nodes running on dedicated signaling servers. The signaling function 14 determines the route of each packet as it leaves the transmitting client device (e.g., a cell phone), based on the condition (e.g., propagation delays) of the network and the priority 16 and urgency of the call, and informs each of the media nodes along the route that it will 17 receive the packet and instructs the node where to send it. Each packet is identified by a 18 tag, and the signaling function instructs each media node what tag to apply to each of the 19 packets it sends. In one embodiment, the data tag is included in a SDNP header or sub header, a data field attached to each data sub-packet used to identify the sub-packet. Each 21 sub-packet may contain data segments from one or multiple sources stored in specific 22 data "slots" in the packet. Multiple sub-packets may be present within one larger data 23 packet during data transport between any two media nodes. 24 The routing function is aligned with the splitting and mixing functions, since once a packet is split, the respective routes of each of the sub-packets into which it is split must 26 be determined and the node where the sub-packets are recombined (mixed) must be 27 instructed to mix them. A packet may be split once and then mixed, as in multiroute 28 embodiments, or it may be split and mixed multiple times as it proceeds through the 29 SDNP network to the exit gateway node. The determination of at which node a packet will be split, into how many sub-packets it will be split, the respective routes of the sub 31 packets, and at what node the sub-packets will be mixed so as to recreate the original

1 packet, are all under the control of the signaling function, whether or not it is performed 2 by separate signaling servers. A splitting algorithm may specify which data segments in a 3 communication are to be included in each of the sub-packets, and the order and positions 4 of the data segments in the sub-packets. A mixing algorithm reverses this process at the node where the sub-packets are mixed so as to recreate the original packet. Of course, if 6 so instructed by the signaling function, that node may also split the packet again in 7 accordance with a different splitting algorithm corresponding to the time or state when 8 the splitting process occurs. 9 When a media node is instructed by the signaling function to send a plurality of packets to a particular destination media node on the "next hop" through the network, 11 whether these packets are split packets (sub-packets) or whether they pertain to different 12 messages, the media node may combine the packets into a single larger packet especially 13 when multiple sub-packets share a common destination media node for their next hop 14 (analogous to a post office putting a group of letters intended for a single address into a box and sending the box to the address). 16 In "dynamic" embodiments of the invention, the individual media nodes in the 17 SDNP cloud do not use the same scrambling, encryption or splitting algorithms or 18 methods on successive packets that pass through them. For example, a given media node 19 might scramble, encrypt or split one packet using a particular scrambling, encryption or splitting algorithm, and then scramble, encrypt or split the next packet using a different 21 scrambling, encryption or splitting algorithm. "Dynamic" operation greatly increases the 22 difficulties faced by would-be hackers because they have only a short period of time 23 (e.g., 1OOmsec) in which to understand the meaning of a packet, and even if they are 24 successful, the usefulness of their knowledge would be short-lived. In dynamic embodiments each media node is associated with what is known as a 26 "DMZ server," which can be viewed as a part of the node that is isolated from the data 27 transport part, and which has a database containing lists or tables ("selectors") of possible 28 scrambling, encryption, and splitting algorithms that the media node might apply to 29 outgoing packets. The selector is a part of a body of information referred to as "shared secrets," since the information is not known even to the media nodes, and since all DMZ 31 servers have the same selectors at a given point in time.

1 When a media node receives a packet that has been scrambled, in dynamic 2 embodiments it also receives a "seed" that is used to indicate to the receiving node what 3 algorithm is to be used in unscrambling the packet. The seed is a disguised numerical 4 value that has no meaning by itself but is based on a constantly changing state, such as the time at which the packet was scrambled by the prior media node. When the prior node 6 scrambled the packet its associated DMZ server generated the seed based on the state. Of 7 course, that state was also used by its associated DMZ server in selecting the algorithm to 8 be used in scrambling the packet, which was sent to the sending media node in the form 9 of an instruction as to how to scramble the packet. Thus the sending node received both the instruction on how to scramble the packet and the seed to be transmitted to the next 11 media node. A seed generator operating within the DMZ server generates the seed using 12 an algorithm based on the state at the time the process is executed. Although the seed 13 generator and its algorithms are part of the media node's shared secrets, the generated 14 seed is not secret because without access to the algorithms the numerical seed has no meaning. 16 Thus the next media note on the packet's route receives the scrambled packet and 17 the seed that is derived from the state associated with the packet (e.g., the time at which it 18 was scrambled). The seed may be included in the packet itself or it may be sent to the 19 receiving node prior to the packet, either along the same route as the packet or via some other route, such as through a signaling server. 21 Regardless of how it receives the seed, the receiving node sends the seed to its 22 DMZ server. Since that DMZ server has a selector or table of scrambling algorithms that 23 are part of the shared secrets and are therefore the same as the selector in the sending 24 node's DMZ server, it can use the seed to identify the algorithm that was used in scrambling the packet and can instruct the receiving node how to unscramble the packet. 26 The receiving node thus recreates the packet in its unscrambled form, thereby recovering 27 the original data. Typically, the packet will be scrambled again according to a different 28 scrambling algorithm before it is transmitted to the next node. If so, the receiving node 29 works with its DMZ server to obtain a scrambling algorithm and seed, and the process is repeated.

1 Thus, as the packet makes its way through the SDNP network, it is scrambled 2 according to a different scrambling algorithm by each node, and a new seed is created at 3 each node that enables the next node to unscramble the packet. 4 In an alternative embodiment of the invention, the actual state (e.g., time) may be transmitted between nodes (i.e., the sending node need not send a seed to the receiving 6 node). The DMZ servers associated with both the sending and receiving media nodes 7 contain hidden number generators (again, part of the shared secrets) that contain identical 8 algorithms at any given point in time. The DMZ server associated with the sending node 9 uses the state to generate a hidden number and the hidden number to determine the scrambling algorithm from a selector or table of possible scrambling algorithms. The 11 sending node transmits the state to the receiving node. Unlike seeds, hidden numbers are 12 never transmitted across the network but remain an exclusively private communication 13 between the media node and its DMZ server. When the receiving media node receives the 14 state for an incoming data packet, the hidden number generator in its associated DMZ server uses the state to generate an identical hidden number, which is then used with the 16 selector or table to identify the algorithm to be used in unscrambling the packet. The state 17 may be included with the packet or may be transmitted from the sending node to the 18 receiving node prior to the packet or via some other route. 19 The techniques used in dynamic encryption and splitting are similar to that used in dynamic scrambling, but in dynamic encryption "keys" are used in addition to seeds. 21 The shared secrets held by the DMZ servers include selectors or tables of encryption and 22 splitting algorithms and key generators. In the case of symmetric key encryption, the 23 sending node transmits a key to the receiving media node which can be used by the 24 receiving node's DMZ server to identify the algorithm used in encrypting the packet and thereby decrypt the file. In the case of asymmetric key encryption, the media node 26 requesting information, i.e. the receiving node first sends an encryption key to the node 27 containing the data packet to be sent. The sending media node then encrypts the data in 28 accordance with that encryption key. Only the receiving media node generating the 29 encryption key holds the corresponding decryption key and the ability to decrypt the ciphertext created using the encryption key. Importantly, in asymmetric encryption access

1 to the encryption key used for encryption does not provide any information as to how to 2 decrypt the data packet. 3 In the case of splitting, the media node where the packet was split transmits a seed 4 to the media node where the resulting sub-packets will be mixed, and the DMZ server associated with the mixing node uses that seed to identify the splitting algorithm and 6 hence the algorithm to be used in mixing the sub-packets. 7 As indicated above, in dual- or tri-channel embodiments, the signaling function is 8 performed by a signaling node operating on separate group of servers known as signaling 9 servers. In such embodiments the seeds and keys may be transmitted through the signaling servers instead of from the sending media node directly to the receiving media 11 node. Thus the sending media node may send a seed or key to a signaling server, and the 12 signaling server may forward the seed or key to the receiving media node. As noted 13 above, the signaling servers are responsible for designing the routes of the packet, so the 14 signaling server knows the next media node to which each packet is directed. To make things more difficult for would-be hackers, the list or table of possible 16 scrambling, splitting or encryption methods in a selector may be "shuffled" periodically 17 (e.g., hourly or daily) in such a way that the methods corresponding to particular seeds or 18 keys are changed. Thus the encryption algorithm applied by a given media node to a 19 packet created at time ti on Day 1 might be different from the encryption algorithm it applies to a packet created at the same time ti on Day 2. 21 Each of the DMZ servers is typically physically associated with one or more 22 media nodes in the same "server farm." As noted above, a media node may request 23 instructions on what to do with a packet it has received by providing its associated DMZ 24 server with a seed or key (based for example on the time or state that the packet was created), but the media node cannot access the shared secrets or any other data or code 26 within the DMZ server. The DMZ server responds to such requests by using the seed or 27 key to determine what method the media node should use in unscrambling, decrypting or 28 mixing a packet. For example, if the packet has been scrambled and the media node 29 wants to know how to unscramble it, the DMZ server may examine a list (or selector) of scrambling algorithms to find the particular algorithm that corresponds to the seed. The 31 DMZ then instructs the media node to unscramble the packet in accordance with that

1 algorithm. In short, the media node transmits inquiries embodied in seeds or keys to the 2 DMZ server, and the DMZ server responds to those inquiries with instructions. 3 While the media nodes are accessible through the Internet (although they do not 4 have DNS recognized IP addresses), the DMZ servers are completely isolated from the Internet having only local network connections via wires or optical fiber to the network 6 connected media servers.. 7 In "single-channel" embodiments, the seeds and keys are transmitted between the 8 sending media node and the receiving media node as a part of the data packet itself, or 9 they may be transmitted in a separate packet before the data packet on the same route as the data packet. For example, when encrypting a packet, media node #1 may include in 11 the packet an encryption key based on the time at which the encryption was performed. 12 When the packet arrives at media node #2, media node #2 transmits the key to its 13 associated DMZ server, and the DMZ server may use the key to select a decryption 14 method in its selector and to perform the decryption. Media node #2 may then ask its DMZ server how it should encrypt the packet again, before transmitting it to media node 16 #3. Again, the DMZ server consults the selector, informs media node #2 what method it 17 should use in encrypting the packet, and delivers to media node #2 a key that reflects a 18 state corresponding to the encryption method. Media node #2 performs the encryption 19 and transmits the encrypted packet and the key (either separately or as a part of the packet) to media node #3. The key may then be used in a similar manner by media node 21 #3 to decrypt the packet, and so on. As a result, there is no single, static decryption 22 method that a hacker could use in deciphering the packets. 23 The use of time or a dynamic "state" condition in the example above as the 24 determinant of the scrambling encryption or splitting method to be embodied in the seed or key is only illustrative. Any changing parameter, e.g., the number of nodes that the 26 packet has passed through, can also be used as the "state" in the seed or key for selecting 27 the particular scrambling, encryption or splitting method to be used. 28 In "dual-channel" embodiments, the seeds and keys can be transmitted between 29 the media nodes via a second "command and control" channel made up of signaling servers rather than being transported directly between the media nodes. The signaling 31 nodes may also provide the media nodes with routing information and inform the media

1 nodes along the route of a packet how the packet is to be split or mixed with other 2 packets, and they instruct each media node to apply an identification "tag" to each packet 3 transmitted so that the next media node(s) will be able to recognize the packet(s). The 4 signaling servers preferably supply a given media node with only the last and next media node of a packet traversing the network. No individual media node knows the entire route 6 of the packet through the SDNP cloud. In some embodiments the routing function may 7 be split up among two or more signaling servers, with one signaling server determining 8 the route to a particular media node, a second signaling server determining the route from 9 there to another media node, and so on to the exit gateway node. In this manner, no single signaling server knows the complete routing of a data packet either. 11 In "tri-channel" embodiments, a third group of servers - called "name servers" 12 are used to identify elements within the SDNP cloud and to store information regarding 13 the identity of devices connected to the SDNP cloud and their corresponding IP or SDNP 14 addresses. In addition, the name servers constantly monitor the media nodes in the SDNP cloud, maintaining, for example, a current list of active media nodes and a table of 16 propagation delays between every combination of media nodes in the cloud. In the first 17 step in placing the call, a client device, such as a tablet, may send an IP packet to a name 18 server, requesting an address and other information for the destination or person to be 19 called. Moreover, a separate dedicated name server is used to operate as a first contact whenever a device first connects, i.e. registers, on the cloud. 21 As an added security benefit, separate security "zones," having different selectors, 22 seed and key generators and other shared secrets, may be established within a single 23 SDNP cloud. Adjacent zones are connected by bridge media nodes, which hold the 24 shared secrets of both zones and have the ability to translate data formatted in accordance with the rules for one zone into data formatted in accordance with the rules for the other 26 zone, and vice versa. 27 Similarly, for communication between different SDNP clouds, hosted for example 28 by different service providers, a full-duplex (i.e., two-way) communication link is formed 29 between interface bridge servers in each cloud. Each interface bridge server has access to the relevant shared secrets and other security items for each cloud.

1 An important advantage of the disclosed invention is that there is no single point 2 of control in the SDNP network and that no node or server in the network has a complete 3 picture as to how a given communication is occurring or how it may be dynamically 4 changing. For example, signaling nodes running on signaling servers know the route (or in 6 some cases only only part of a route) by which a communication is occurring, but they do 7 not have access to the data content being communicated and do not know who the real 8 callers or clients are. Moreover, the signaling nodes do not have access to the shared 9 secrets in a media node's DMZ servers, so they do not know how the data packets in transit are encrypted, scrambled, split or mixed, 11 The SDNP name servers know the true phone numbers or IP addresses of the 12 callers but do not have access to the data being communicated or the routing of the 13 various packets and sub-packets. Like the signaling nodes, the name servers do not have 14 access to the shared secrets in a media node's DMZ servers, so they do not know how the data packets in transit are encrypted, scrambled, split or mixed. 16 The SDNP media nodes actually transporting the media content have no idea who 17 the callers communicating are nor do they know the route the various fragmented sub 18 packets are taking through the SDNP cloud. In fact each media node knows only what 19 data packets to expect to arrive (identified by their tags or headers), and where to send them next, i.e. the "next hop," but the media nodes do not know how the data is 21 encrypted, scrambled, mixed or split, nor do they know how to select an algorithm or 22 decrypt a file using a state, a numeric seed, or a key. The knowhow required to correctly 23 process incoming data packets' data segments is known only by the DMZ server, using 24 its shared secrets, algorithms not accessible over the network or by the media node itself Another inventive aspect of the disclosed invention is its ability to reduce network 26 latency and minimize propagation delay to provide superior quality of service (QoS) and 27 eliminate echo or dropped calls by controlling the size of the data packets, i.e. sending 28 more smaller data packets in parallel through the cloud rather than relying on one high 29 bandwidth connection. The SDNP network's dynamic routing uses its knowledge of the network's node-to-node propagation delays to dynamically select the best route for any 31 communication at that moment. In another embodiment, for high-priority clients the

1 network can facilitate race routing, sending duplicate messages in fragmented form 2 across the SDNP cloud selecting only the fastest data to recover the original sound or 3 data content. 4 Among the many advantages of an SDNP system according to the invention, in parallel and "meshed transport" embodiments the packets may be fragmented as they 6 transit the SDNP cloud, preventing potential hackers from understanding a message even 7 if they are able to decipher an individual sub-packet or group of sub-packets, and in 8 "dynamic" embodiments the scrambling, encryption and splitting methods applied to the 9 packets are constantly changing, denying to a potential hacker any significant benefit from successfully deciphering a packet at a given point in time. Numerous additional 11 advantages of embodiments of the invention will be readily evident to those of skill in the 12 art from a review of the following description. 13 Similar security techniques may generally be applied in the "last mile" between 14 an SDNP cloud and a client device, such as a cell phone or a tablet. The client device is normally placed in a separate security zone from the cloud, and it may first become an 16 authorized SDNP client, a step that involves installing in the client device a software 17 package specific to the device's security zone, typically via a download from an SDNP 18 administration server. The client device is linked to the SDNP cloud through a gateway 19 media node (sometimes referred to as just a "gateway") in the cloud. The gateway media node has access to the shared secrets pertaining to both the cloud and the client's device's 21 security zone, but the client device does not have access to the shared secrets pertaining 22 to the SDNP cloud. 23 As an added level of security, the client devices may exchange seeds and keys 24 directly with each other via the signaling servers. Thus a transmitting client device may send a seed and/or key directly to the receiving client device. In such embodiments the 26 packet received by the receiving client device will be in the same scrambled or encrypted 27 form as the packet leaving the sending client device. The receiving client device can 28 therefore use the seed or key that it receives from the sending client device to unscramble 29 or decrypt the packet. The exchange of seeds and keys directly between client devices is in addition to the SDNP network's own dynamic scrambling and encrypting, and it thus 31 represents an added level of security called nested security.

1 In addition, a client device or the gateway node with which it communicates may 2 mix packets that represent the same kind of data-e.g. voice packets, text message files, 3 documents, pieces of software, or that represent dissimilar types of information, e.g. one 4 voice packet and one text file, one text packet, and one video or photo image-before the packets reach the SDNP network, and the exit gateway node or destination client device 6 may split the mixed packet to recover the original packets. This is in addition to any 7 scrambling, encryption or splitting that occurs in the SDNP network. In such cases, the 8 sending client device may send the receiving client device a seed instructing it how to 9 split the packet so as to recreate the original packets that were mixed in the sending client device or gateway media node. Performing successive mixing and splitting may comprise 11 a linear sequence of operations or alternatively utilize a nested architecture where the 12 clients execute their own security measures and so does the SDNP cloud. 13 To further confuse would-be hackers, a client device may transmit successive 14 packets (or sub-packets) in a single communication to different gateway nodes, and/or it may transmit them over different physical media links (cellular, WiFi, Ethernet cable, 16 etc.)-a process referred to sometimes herein as "Multi-PHY" transmission. To add to 17 the confusion, it may also include different source addresses in the successive packets, 18 thereby preventing a hacker from identifying the packets as originating from the same 19 client device. The invention also includes unique advances in the handling of telephone 21 conference calls. In a normal conference call packets are sent to all of the participants in 22 the call. In accordance with this invention, certain designated participants may be 23 "muted," i.e., excluded from the call by preventing a client device or other node from 24 transmitting packets to the participant or participants who are to be muted. In an alternative embodiment data packets are sent in broadcast mode to all participants in the 26 group call but using different encryption methods. In the case of normal conference calls 27 the data packets are sent to all users using an encryption where all participants have a 28 copy of the decryption key. In private mode or mute mode the data packets broadcasted 29 to the users utilize a different encryption where only select users share the decryption key.

1 The security mechanisms intrinsic to communication using the SDNP network 2 and protocol also render it perfectly suited for secure file and data storage. Since a normal 3 communication over the SDNP network typically involves anonymous fragmented data 4 transport of scrambled, encrypted data from one from one client device to another client device, file and data storage can be realized by, in effect, interrupting a communication in 6 transit and storing it in one or more buffers indefinitely until the originating client device 7 wishes to retrieve it. This distributed file storage is sometimes referred to herein as 8 Disaggregated Data Storage. 9 According to another aspect, there is provided a method of transmitting data packets from a client device to a cloud, the data packets being comprised in a 11 communication, the cloud comprising a plurality of media nodes and a plurality of 12 gateway nodes, wherein: 13 the client device transmits a call request to a signaling server, the call request 14 containing contact information regarding a party to be called; the signaling server develops routes for a communication directed to the party to be called, a first route 16 comprising a first gateway node and a second route comprising a second gateway node, 17 neither the first gateway node, the second gateway node; nor any other media node having 18 information describing either the first route or the second route in total; the signaling 19 server transmits routing instruction packets to the client device, the first gateway node and the second gateway node, respectively; and in response to a routing instruction 21 packet, the client device transmits a first data packet in the communication from the client 22 device to the first gateway node and a second data packet in the communication from the 23 client device to the second gateway node. 24 According to another aspect, there is provided a method of transmitting data packets from a client device to a cloud, the data packets being comprised in a 26 communication, the cloud comprising a plurality of media nodes and a plurality of 27 gateway nodes, the method comprising: transmitting a first data packet from the client 28 device to a first gateway node through at least one router; providing the first data packet 29 with a first IP source address and afirst MAC source address; transmitting a second data packet and from the client device to a second gateway node through at least one router; 31 and providing the second data packet with a second IP source address and a second MAC 32 source address. 33

1 Brief Description of the Drawings 2 In the drawings listed below, components that are generally similar are given like 3 reference numerals. It is noted, however, that not every component to which a given 4 reference number is assigned is necessarily identical to another component having the same reference number. For example, an encryption operation having a particular 6 reference number is not necessarily identical to another encryption operation with the 7 same reference number. Furthermore, groups of components, e.g., servers in a network 8 that are identified collectively by a single reference number are not necessarily identical 9 to each other. Fig. 1 is a schematic diagram showing conventional packet transport across a 11 network. 12 Fig. 2A is a schematic diagram showing the process of packet scrambling. 13 Fig. 2B is a schematic diagram showing the process of packet unscrambling. 14 Fig. 2C is a schematic diagram showing various packet scrambling algorithms. Fig. 2D is a schematic diagram showing static parametric packet scrambling. 16 Fig. 2E is a schematic diagram showing dynamic scrambling with a hidden 17 number. 18 Fig. 3 is a schematic diagram showing the packet re-scrambling process. 19 Fig. 4A is a schematic diagram showing the process of packet encryption. Fig. 4B is a schematic diagram showing the process of packet decryption. 21 Fig. 5 is a schematic diagram showing the process of encrypted scrambling and 22 its inverse function.

51a

1 Fig. 6 is a schematic diagram showing the process of DUSE re-packeting 2 comprising re-scrambling and re-encryption. 3 Fig. 7A is a schematic diagram showing the process of fixed-length packet 4 splitting. Fig. 7B is a schematic diagram showing the process of fixed-length packet 6 mixing. 7 Fig. 8 is a schematic diagram showing various packet-mixing methods. 8 Fig. 9A is a table summarizing SDNP security functions and anti-functions. 9 Fig. 9B is a block diagram illustrating SDNP security operations performed on incoming and outgoing data packets for single route Last Mile communication. 11 Fig. 9C is a block diagram illustrating SDNP security operations performed on 12 incoming and outgoing data packets for multi-route Last Mile communication. 13 Fig. 9D is a block diagram illustrating audio, video, textual, and file content 14 creation, data packet preparation, data packet recognition, and content reproduction in a SDNP client device. 16 Fig. 9E is a graphical representation of a SDNP data packet using the 7-Layer 17 OSI model to illustrate hierarchical data encapsulation. 18 Fig. 9F is a graphical and tabular representation of a SDNP payload. 19 Fig. 9G is a block diagram illustrating inbound Last Mile data packet processing in SDNP gateway using tri-channel communication. 21 Fig. 9H is a block diagram illustrating inbound Last Mile data packet processing 22 in SDNP gateway using single-channel communication. 23 Fig. 91 is a block diagram illustrating outbound Last Mile data packet processing 24 in SDNP gateway using tri-channel communication. Fig. 10 is a schematic representation of SDNP cloud. 26 Fig. 11 schematically represents examples of unsecure last mile communication 27 without identity verification. 28 Fig. 12 illustrates unsecure last mile communication over a plain old telephone 29 system (POTS) lacking identity verification of callers. Fig. 13 schematically represents examples of unsecure last mile communication 31 with identity verification.

1 Fig. 14 illustrates unsecure last mile communication over an analog public service 2 telephone network (PSTN) with operator-based identity verification. 3 Fig. 15 illustrates unsecure last mile communication over a wireline digital 4 network with login- or token-based identity verification. Fig. 16 illustrates unsecure last mile communication over a wireline analog 6 network with PIN- or credit-card based identity verification. 7 Fig. 17schematically represents examples of HyperSecure last mile 8 communication capable of supporting identity verification. 9 Fig. 18 illustrates identity-verifiable HyperSecure last mile communication over a WiFi wireless network. 11 Fig. 19 illustrates identity-verifiable HyperSecure last mile communication over a 12 cellular wireless network. 13 Fig. 20 illustrates identity-verifiable HyperSecure last mile communication over 14 an Ethernet wireline network. Fig. 21 illustrates identity-verifiable HyperSecure last mile communication over a 16 cable wireline network. 17 Fig. 22 illustrates identity-verifiable HyperSecure last mile communication over 18 combined cable wireline and home WiFi wireless networks. 19 Fig. 23 schematically represents an example of last mile communication comprising an identity-verifiable HyperSecure communication leg connected to an 21 identity-paired secure LAN last link. 22 Fig. 24 illustrates last mile communication comprising an identity-verifiable 23 HyperSecure wireline communication leg connected by wireline to identity-paired secure 24 devices and to unidentified unsecure devices. Fig. 25illustrates last mile communication comprising an identity-verifiable 26 HyperSecure wireline communication leg connected by WiFi LAN to identity-paired 27 WPA-secured computing and communication devices for home and work. 28 Fig. 26 illustrates last mile communication comprising an identity-verifiable 29 HyperSecure wireline communication leg connected by WiFi LAN to identity-paired WPA-secured home IoT devices.

1 Fig. 27 illustrates last mile communication comprising an identity-verifiable 2 HyperSecure wireline communication leg connected by Ethernet or by WiFi LAN to 3 identity-paired WPA-secured devices for business. 4 Fig. 28 schematically represents an example of last mile communication comprising identity-verifiable HyperSecure communication legs connected to identity 6 paired secure wired or secure wireless LAN last links. 7 Fig. 29A schematically represents wireline and wireless HyperSecure bridges 8 comprising Ethernet and WiFi applicable in last mile communication. 9 Fig. 29B schematically represents wireline and wireless HyperSecure bridges utilizing satellite and automotive networks applicable in last mile communication. 11 Fig. 29C schematically represents wireline and wireless HyperSecure bridges 12 utilizing cable and cellular networks applicable in last mile communication 13 Fig. 30 illustrates last mile communication comprising an identity-verifiable 14 HyperSecure wireless communication via satellite uplinks and downlinks to various devices including sat phones, airplanes, trains, ships, and home satellite receivers (set top 16 boxes). 17 Fig. 31A is an example of last link HyperSecure communication among devices 18 in an onboard airplane communication network with satellite connectivity. 19 Fig. 31B is an example of an airplane satellite communication and antenna module. 21 Fig. 32 is an example of last link HyperSecure communication among devices in 22 an onboard ocean cruise ship communication network with multiple channels of satellite 23 connectivity. 24 Fig. 33 is an example of last mile HyperSecure communication among devices in an onboard train communication network with radio and satellite connectivity. 26 Fig. 34 illustrates HyperSecure last mile communication to an automotive 27 telematics module including cellular last link connectivity. 28 Fig. 35 is an example of last link communication between the telematics modules 29 in an automotive communication network with cellular connectivity and in-cabin WiFi connected devices.

1 Fig. 36 is an example of HyperSecure inter-vehicular communication with 2 cellular connectivity. 3 Fig.37 illustrates HyperSecure trunk line communication over microwave, 4 satellite, and fiber networks. Fig. 38 illustrates a comparison of security, identity verification, and caller 6 anonymity features for HyperSecure, secure, and unsecure communication networks. 7 Fig. 39 is a schematic representation of single-route last mile HyperSecure 8 communication with static IP addresses. 9 Fig. 40A is a schematic IP stack depiction of single-route last mile HyperSecure communication using static IP addresses. 11 Fig. 40B is a simplified representation of single-route last mile HyperSecure 12 communication using static IP addresses. 13 Fig. 41 is a schematic representation of single-route last mile HyperSecure 14 communication with dynamic client IP addresses. Fig. 42A is an IP stack depiction of single-route last mile HyperSecure 16 communication using dynamic client IP addresses. 17 Fig. 42B is an alternate IP stack representation of single-route last mile 18 HyperSecure communication employing dynamic client IP addresses. 19 Fig. 43 is a schematic representation of multi-route last mile HyperSecure communication with static IP addresses. 21 Fig. 44A is an IP stack depiction of multi-route last mile HyperSecure 22 communication with static IP addresses using a single PHY last link. 23 Fig. 44B is an IP stack depiction of multi-route last mile HyperSecure 24 communication with static IP addresses using multiple PHY last links. Fig. 45 is a schematic representation of multi-route last mile HyperSecure 26 communication with dynamic client IP addresses. 27 Fig. 46A is an IP stack depiction of multi-route last mile HyperSecure 28 communication with dynamic client IP addresses using a single PHY last link. 29 Fig. 46B is an IP stack depiction of multi-route last mile HyperSecure communication with dynamic client IP addresses using multiple PHY last links.

1 Fig. 47 is a schematic representation of an alternate version of multi-route last 2 mile HyperSecure communication with dynamic client IP addresses. 3 Fig. 48 is an IP stack depiction of an alternate version of multi-route last mile 4 HyperSecure communication with dynamic client IP addresses. Fig. 49 is a graphical representation of IPv4 and IPv6 datagrams for Ethernet 6 communication carrying a SDNP payload. 7 Fig. 50A is a graphical representation of IPv4 and IPv6 Last Link Ethernet 8 packets used in client to SDNP-cloud communication. 9 Fig. 50B is a graphical representation of IPv4 and IPv6 Gateway Link Ethernet packets used in client to SDNP-cloud communication. 11 Fig. 50C is a graphical representation of IPv4 and IPv6 Gateway Link Ethernet 12 packets used in SDNP-cloud to client communication. 13 Fig. 50D is a graphical representation of IPv4 and IPv6 Last Link Ethernet 14 packets used in SDNP-cloud to client communication. Fig. 51A illustrates successive Ethernet data packets (abridged) used in single 16 route Last Mile communication with static client addressing. 17 Fig. 51B illustrates successive Ethernet data packets (abridged) used in single 18 route Last Mile communication with dynamic client addressing. 19 Fig. 51C illustrates successive Ethernet data packets (abridged) used in multi route Last Mile communication with static client addressing. 21 Fig. 51D illustrates successive Ethernet data packets (abridged) used in multi 22 route Last Mile communication with dynamic client addressing. 23 Fig. 52A is a table summarizing SDNP Last Mile routing over Ethernet. 24 Fig. 52B are topological descriptions of single route Last Mile communication over Ethernet. 26 Fig. 52C are topological descriptions of multi-route Last Mile communication 27 over Ethernet. 28 Fig. 52D are additional topological descriptions of multi-route Last Mile 29 communication over Ethernet. Fig. 53 is a graphical representation of IPv4 and IPv6 datagrams for WiFi 31 communication carrying a SDNP payload.

1 Fig. 54A is a graphical representation of IPv4 and IPv6 Last Link WiFi packets 2 used in client to SDNP-cloud communication. 3 Fig. 54B is a graphical representation of IPv4 and IPv6 Gateway Link WiFi 4 packets used in client to SDNP-cloud communication. Fig. 54C is a graphical representation of IPv4 and IPv6 Gateway Link WiFi 6 packets used in SDNP-cloud to client communication. 7 Fig. 54D is a graphical representation of IPv4 and IPv6 Last Link WiFi packets 8 used in SDNP-cloud to client communication. 9 Fig. 55 is a graphical representation of IPv4 and IPv6 datagrams for 4G cellular communications carrying a SDNP payload. 11 Fig. 56A is a graphical representation of IPv4 and IPv6 Last Link 4G cellular data 12 packets used in client to SDNP-cloud communication. 13 Fig. 56B is a graphical representation of IPv4 and IPv6 Last Link 4G cellular 14 packets used in SDNP-cloud to client communication. Fig. 57A is a graphical representation of single-media multi-PHY Last Link 16 communication. 17 Fig. 57B is a graphical representation of mixed-media multi-PHY Last Link 18 communication. 19 Fig. 57C is a graphical representation of alternative implementations of multi PHY Last Link communication. 21 Fig. 58 is a graphical representation of successive client to SDNP-cloud Last Link 22 communications using IPv6 datagrams delivered over multi-PHY Ethernet. 23 Fig. 59 is a graphical representation of successive client to SDNP-cloud Last Link 24 communications using IPv6 datagrams delivered over multi-PHY WiFi. Fig. 60 is a graphical representation of successive client to SDNP-cloud Last Link 26 communications using IPv6 datagrams delivered over multi-PHY 4G cellular networks. 27 Fig. 61 is a graphical representation of successive client to SDNP-cloud Last Link 28 communications using IPv6 datagrams using multi-PHY delivery over Ethernet and 29 WiFi.

1 Fig. 62 is a graphical representation of successive client to SDNP-cloud Last Link 2 communications using IPv6 datagrams using multi-PHY delivery over and WiFi and 4G 3 cellular networks. 4 Fig. 63 is a schematic representation of an OSI layer stack construct of a DOCSIS cable modem communication network illustrating Layer 1 through Layer 7 functionality. 6 Fig. 64 is a graphical representation of DOCSIS3 base communication packets 7 made for cable systems carrying a SDNP payload. 8 Fig. 65A is a graphical representation of spectrum allocation and carrier 9 modulation methods for various DOCSIS3 protocols. Fig. 65B is a graphical representation of a DOCSIS3.1 communication sequence 11 between CTMS and CM. 12 Fig. 65C is a graphical representation of DOCSIS3.1 upstream communication. 13 Fig. 65D is a graphical representation of DOCSIS3.1 downstream 14 communication. Fig. 66 is a schematic representation of a tri-route SDNP network for Last Mile 16 communication. 17 Fig. 67 is a schematic representation of a "call request" operation in tri-channel 18 SDNP Last Mile communication. 19 Fig. 68 is a schematic representation of an "address request" operation in tri channel SDNP Last Mile communication. 21 Fig. 69 is a schematic representation of an "address delivery" operation in tri 22 channel SDNP Last Mile communication. 23 Fig. 70 is a flow chart illustrating SDNP command and control packet synthesis. 24 Fig. 71 is a schematic representation of a "routing instructions" operation in single-route tri-channel SDNP Last Mile communication. 26 Fig. 72 is a schematic representation of a "SDNP call" operation in single-route 27 tri-channel SDNP Last Mile communication from a SDNP client to the SDNP cloud. 28 Fig. 73A is a schematic representation of SDNP cloud and Last Mile tri-route 29 communication to an SDNP client in a SDNP call. Fig. 73B is a schematic representation of SDNP cloud and Last Mile tri-route 31 communication implemented as a "call out" to a non-SDNP client.

1 Fig. 74 is a schematic representation of a "routing instructions" operation in 2 multi-route tri-channel SDNP Last Mile communication. 3 Fig. 75A is a schematic representation of a "SDNP call" operation in multi-route 4 tri-channel SDNP Last Mile communication in the direction of from a SDNP client to the SDNP cloud. 6 Fig. 75B is a schematic representation of a "SDNP call" operation in multi-route 7 tri-channel SDNP Last Mile communication in the direction from the SDNP cloud to the 8 SDNP client. 9 Fig. 76 is a schematic representation of group-call "routing instructions" operation in single-route tri-channel SDNP Last Mile communication. 11 Fig. 77A is a schematic representation of a "SDNP group call" using SDNP 12 multi-route cloud transport and SDNP Last Mile communication in the direction from a 13 zone U1 client to clients in other zones. 14 Fig. 77B is a schematic representation of a "SDNP group call" using SDNP multi route cloud transport and SDNP Last Mile communication in the direction from a zone 16 U7 client to clients in other zones. 17 Fig. 77C is a schematic representation of a "SDNP group call" using SDNP 18 multi-route cloud transport and SDNP Last Mile communication in the direction from a 19 zone U9 client to other clients on the same zone and in other zones. Fig. 78 is a schematic representation of a "SDNP group call" using SDNP multi 21 route cloud transport and Last Mile communication to both SDNP clients and unsecured 22 PSTN devices. 23 Fig. 79A is a tabular representation of regular call and private call operation in 24 SDNP group calls. Fig. 79B is a tabular representation of regular call and hyper-private call 26 operation in SDNP group calls. 27 Fig. 80A is a tabular representation of regular and private push-to-talk operation 28 in SDNP PTT group calls. 29 Fig. 80B is a tabular representation of regular and hyper-private push-to-talk operation in SDNP PTT group calls.

1 Fig. 81 is a schematic representation of data transport for a write-operation in 2 HyperSecure file storage of fragmented data. 3 Fig 82A is a schematic representation of data flow for a write-operation in 4 HyperSecure file storage of fragmented data. Fig. 82B is a schematic representation of data flow for a read-operation in 6 HyperSecure file storage of fragmented data. 7 Fig. 83 is a schematic representation of data transport for a read-operation in 8 HyperSecure file storage of fragmented data. 9 Fig. 84A illustrates various examples of SDNP cloud connected file storage solutions. 11 Fig. 84B is a schematic representation of a distributed HyperSecure file storage 12 network comprising local and cloud connected storage servers. 13 Fig. 85A is a file mapping for non-redundant (RRF = 0) HyperSecure file storage. 14 Fig. 85B is a file mapping for RRF = 1 read redundant HyperSecure file storage. Fig. 85C is a file mapping for RRF = 2 read redundant HyperSecure file storage. 16 Fig. 86 is a network map for a distributed HyperSecure file storage system using 17 tri-channel network communication. 18 Fig. 87A illustrates the file write request operation in a distributed HyperSecure 19 file storage system. Fig. 87B illustrates the file server name request operation in a distributed 21 HyperSecure file storage system. 22 Fig. 87C illustrates the signaling server planning operation in a distributed 23 HyperSecure file storage system. 24 Fig. 87D illustrates the signaling server client-side Last Mile and SDNP cloud write routing instruction in a distributed HyperSecure file storage system. 26 Fig. 87E illustrates the signaling server storage-side Last Mile and SDNP cloud 27 write routing instruction in a distributed HyperSecure file storage system. 28 Fig. 88 illustrates file transfer in a distributed HyperSecure file storage system. 29 Fig. 89A illustrates link reply confirming file storage and write operation in a distributed HyperSecure file storage system.

1 Fig. 89B illustrates file storage server link transfers in a distributed HyperSecure 2 file storage system. 3 Fig. 89C illustrates file storage server write confirmation data packet containing 4 FS link. Fig. 89D illustrates synthesis of a file storage read link in a client's SDNP 6 messenger 7 Fig. 90A is a file map of non-redundant RRF = 0 HyperSecure file storage with 8 LRF = 0 non-redundant FS links. 9 Fig. 90B is a file map of non-redundant RRF = 0 HyperSecure file storage with LRF = 1 redundant FS links. 11 Fig. 90C is a file map of non-redundant RRF = 1 HyperSecure file storage with 12 LRF = 1 redundant FS links. 13 Fig. 91 is a graph representing storage resiliency as a function of the number of 14 file storage servers and client FS links. Fig. 92 is a schematic representation of SDNP-encode and SDNP-decode 16 functions. 17 Fig. 93A is a schematic representation of SDNP distributed file storage with 18 client side file security and HyperSecure file transport. 19 Fig. 93B is a schematic representation of SDNP distributed file storage with nested file security and HyperSecure file transport. 21 Fig. 94 is a simplified schematic representation of HyperSecure encoding in 22 SDNP distributed file storage write operations. 23 Fig. 95 is a simplified schematic representation of HyperSecure decoding in 24 SDNP distributed file storage read operations. Fig. 96A is a flow chart describing the AAA operations in a HyperSecure file 26 read operation. 27 Fig. 96B is a flow chart describing file access and SDNP transport in a 28 HyperSecure file read operation. 29 Fig. 97A illustrates the file read request operation in a distributed HyperSecure file storage system.

1 Fig. 97B illustrates the file storage server name request operation in a distributed 2 HyperSecure file storage system. 3 Fig. 97C illustrates the file storage server name delivery and signaling server 4 planning operation in a distributed HyperSecure file storage system. Fig. 97D illustrates the signaling server storage-side Last Mile and SDNP cloud 6 routing read instruction in a distributed HyperSecure file storage system. 7 Fig. 97E illustrates the signaling server client-side Last Mile and SDNP cloud 8 read routing instruction in a distributed HyperSecure file storage system. 9 Fig. 98 illustrates storage side file decoding during a read operation in a distributed HyperSecure file storage system. 11 Fig. 99 illustrates file data transfers in a distributed HyperSecure file storage 12 system during a read operation. 13 Fig. 100 illustrates file data transfers in a distributed HyperSecure file storage 14 system during a link refresh. Fig. 101 illustrates file data transfers in a distributed HyperSecure file storage 16 system used to redistribute files. 17 Fig. 102 illustrates time stamps in SDNP text messaging. 18 Fig. 103 is a flow chart of SDNP registered communication. 19 Fig. 104A illustrates end-to-end encryption in Internet OTT communication. Fig. 104B illustrates end-to-end encryption in HyperSecure communication. 21 Fig. 105A is a schematic representation of a "SDNP call" operation with a SDNP 22 security agent performing invisible monitoring of an outgoing call. 23 Fig. 105B is a schematic representation of a "SDNP call" operation with a SDNP 24 security agent performing invisible monitoring of an incoming call. Fig. 106 illustrates file storage server link transfers in a distributed HyperSecure 26 file storage system with a SDNP security agent performing invisible monitoring of the FS 27 link routing. 28 Fig. 107 is a schematic representation of a "SDNP call" operation with a SDNP 29 security agent performing invisible monitoring of an outgoing call employing multi-route Last Mile communication.

1 Fig. 108 is a flow chart of the steps to designate and authorize a SDNP security 2 agent 3 Fig. 109 illustrates cell phone to tower communication subject to SS7 4 vulnerabilities. Fig. 110 illustrates SDNP communication using phone number camouflaging to 6 repel SS7 attacks. 7 Fig. 111 illustrates connectivity of SDNP SoftSwitch-based clouds hosted on 8 separate servers. 9 Fig. 112 illustrates connectivity of SDNP SoftSwitch-based clouds hosted on shared servers. 11 Fig. 113 illustrates connectivity of SDNP SoftSwitch-Based clouds hosted on 12 overlapping networks. 13 Fig. 114 illustrates connectivity of SDNP SoftSwitch-Based clouds accessing 14 global SDNP cloud telco. Fig. 115 is an example of a nested SDNP subnet. 16 17 18 19 Description of the Invention After nearly one-and-a-half centuries of circuit-switched telephony, today's 21 communication systems and networks have within only a decade all migrated to packet 22 switched communication using the Internet Protocol carried by Ethernet, WiFi, 4G/LTE, 23 and DOCSIS3 data over cable and optical fiber. The benefits of comingling voice, text, 24 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 26 unparalleled level of system interoperability and connectivity across the globe. With any 27 innovation, however, the magnitude of challenges new technology creates often match 28 the benefits derived. 29 Disadvantages of Existing Communication Providers

1 As detailed throughout the background section of this disclosure, present-day 2 communication suffers from many disadvantages. The highest performance 3 communication systems today, comprising custom digital hardware owned by the world's 4 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 6 fees, connection fees, long-distance fees, complex data rate plans, long-distance roaming 7 charges, and numerous service fees. Because these networks are private, the actual data 8 security is not publically known, and security infractions, hacks, and break-ins are 9 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 11 in their private cloud, in the very least in their last-mile connections. 12 "Internet service providers" or ISPs form another link in the global chain of 13 communications. As described in the background of this invention, voice carried over the 14 Internet using VoP, or "voice over Internet protocol" suffers from numerous quality-of service or QoS problems, including 16 • The Internet, a packet-switched network, is not designed to deliver 17 IP packets in a timely manner or to support real-time applications with low 18 latency and high QoS 19 • The routing of an IP packet takes an unpredictable path resulting in constantly changing delays, bursts of high data-error rates, and unexpected 21 dropped calls 22 • IP packet routing is made at the discretion of the Internet service 23 provider, which controls the network within which the packet is routed and may 24 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 26 its network. 27 • Over-the-top or OTT providers such as Line, KakaoTalk, Viber, 28 etc. catching a free ride on the Internet act as Internet hitchhikers and have no 29 control over the network or factors affecting QoS. • Using heavyweight audio CODECs that fail to provide 31 comprehendible voice quality audio even at moderate data rates

1 • VoIP based on the TCP transport protocol suffers from high 2 latency and degraded audio caused by delays induced during handshaking and IP 3 packet rebroadcasting. Unaided UDP transport provides no guarantee of payload 4 integrity. Aside from QoS issues, the security of today's devices and networks is abysmal, 6 representing a level totally unacceptable to support the future needs of global 7 communication. As detailed in the background section of the US patent application 8 entitled Secure Dynamic Communication Network and Protocol, network security is 9 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 11 sniffing, wiretaps, and call interception of cyber pirate "faux" cellphone towers; and in 12 the local network or telco portion of last-mile connectivity, involving spyware, IP packet 13 sniffing, infections such as viruses, and cyber pirate "man in the middle attacks". The 14 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, 16 from denial-of-service attacks, and from unauthorized government surveillance. In 17 summary, today's communication security is compromised by numerous vulnerabilities 18 easily exploited by cyber pirates and useful for committing cybercrime and violations of 19 cyberprivacy, including: • Revealing the destination of an IP packet, including the destination 21 IP address, the destination port #, and the destination MAC address. 22 • Revealing the source of an IP packet, including the source IP 23 address, the source port #, and the source MAC address. 24 • 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 26 payload 27 • In unencrypted files, all application and file data encapsulated in 28 the IP packet's payload, including personal and confidential information, login 29 information, application passwords, financial records, videos, and photographs. • A dialog of communications, enabling a cyber party the repeated 31 opportunity to break encrypted files

1 • Numerous opportunities to install malware, including spyware and 2 phishing programs and Trojan horses into communicating devices and routers 3 using FTP, email, and web page based infections 4 Reiterating a key point, the fundamentally intrinsic weakness of packet-switched communication networks using Internet Protocol, is that any hostile party or cyber-pirate 6 intercepting an IP packet can see what devices were involved in creating the data 7 contained with the IP packet, where the IP packet came from, where the IP packet is 8 being sent to, how the data is being transported, i.e. UDP or TCP, and what kind of 9 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, 11 improving their opportunity to crack encryption, break password security, and gain 12 unauthorized access to files, data, and payload content. 13 Encryption - To defend against the diverse range of cyber-assaults as described, 14 present day network managers, IT professionals, and application programs primarily rely on a single defense - encryption. Encryption is a means by which to convert recognizable 16 content also known as "plaintext", whether readable text, executable programs, viewable 17 videos and pictures, or intelligible audio, into an alternate file type known as 18 "ciphertext", that appears as a string of meaningless textual characters. 19 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 21 into equivalent textual elements without revealing any apparent pattern of the 22 encryption's conversion process. The encrypted file is then sent across the 23 communication network or medium until received by the destination device. Upon 24 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 26 encryption and decryption, known broadly as "cryptography", blends elements of 27 mathematics, including number theory, set theory and algorithm design, with computer 28 science and electrical engineering. 29 In simple "single key" or "symmetric key" encryption technologies, a single key word or phrase known aprioriby both parties can be used to unlock the process for 31 encrypting and decrypting a file. In World War II, for example, submarines and ocean

1 ships communicated on open radio channels used encrypted messages. Initially, the 2 encryptions were single-key-based. By analyzing the code pattern, Allied cryptologists 3 were sometimes able to reveal the encryption key word or pattern and thereafter were 4 able to read encrypted files without discovery. As encryption methods became more complex, breaking the code manually became more difficult. 6 Code evolved into mechanical machine-based ciphers, an early form of 7 computing. At the time, the only way to break the code was stealing a cypher machine 8 and using the same tools to decipher a message as those encrypting the files. The 9 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 11 code and update their cypher machines already in operation. This principle is practiced 12 still today - the most effective cyber-assault is one that goes undetected. 13 With the advent of computing and the Cold War, encryption became more 14 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 16 for encrypting information and the ability to crack the encryption code developed nearly 17 at pace. The major next evolutionary step in encryption came in the 1970s with the 18 innovation of dual-key encryption, a principle still in use today. One of the best-known 19 dual key encryption methods is the RSA public key cryptosystem, named after its developers Rivest, Shamir, and Adleman. Despite published recognition for RSA, 21 contemporaneous developers independently conceived of the same principle. RSA 22 employs two cryptographic keys based on two large prime numbers kept secret from the 23 public. One algorithm is used to convert these two prime numbers into an encryption key, 24 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 26 a D-key. The RSA-user who selected the secret prime numbers, herein referred to as the 27 "key publisher', distributes or "publishes" this algorithmically generated E-key 28 comprising typically between 1024b to 4096b in size, to anyone wishing to encrypt a file. 29 Because this key is possibly distributed to many parties in an unencrypted form, the E key is known as a "public key".

1 Parties wishing to communicate with the key publisher then use this public E-key 2 in conjunction with a publically available algorithm, typically offered in the form of 3 commercial software, to encrypt any file to be sent to the particular key publisher. Upon 4 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 6 RSA algorithm in particular is that the public E-key used to encrypt a file cannot be used 7 for decryption. Only the secret D-key possessed by the key publisher has the capability of 8 file decryption. 9 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 11 methodologically specifies a communication method as a sequence of steps. For example, 12 in a dual-key exchange over a switch packet communication network a device, e.g. a 13 notebook wishing to receive a secure file from a cell phone first generates two keys, an 14 E-key for encryption and a D-key for decryption using some algorithm. The notebook then sends the E-key to the cell phone using a public network communication carrying 16 an IP packet. The IP packet in unencrypted form, contains the MAC address, P source 17 address "NB" and port address of the notebook along with the destination P address 18 "CP" and corresponding port of the cell phone as well as the transport protocol TCP and 19 an encrypted copy of an E-key as its payload. Using an agreed upon encryption algorithm or software package, the cell phone 21 then processes a plaintext file using an encryption algorithm and encryption E-key to 22 produce an encrypted file, i.e. ciphertext, carried as a payload of IP packet in a secure 23 communication from the cell phone to the notebook. Upon receiving theTP packet, the 24 algorithm decrypts the file using secret decryption key, i.e. D-key. Since the D-key is made consistent with its corresponding E-key, in essence the algorithm employs 26 knowledge of both keys to decrypt the ciphertext back into unencrypted plaintext 697B. 27 While the payload of IP packet 696 is secured in the form of an encrypted file, i.e. 28 ciphertext, the rest of the IP packet is still unencrypted, sniffable, and readable by any 29 cyber pirate including the source IP address "CP" and port and the destination IP address "NB" and associated port. So even if the payload itself can't be opened, the 31 communication can be monitored.

1 VirtualPrivate Networks - Another security method, also relying on encryption, 2 is that of a "virtual private network" or VPN. In a VPN, a tunnel or secure pipe is formed 3 in a network using encrypted IP packets. Rather than only encrypting the payload, in a 4 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 6 gateway to another. Originally, VPNs were used to connect disparate local area networks 7 together over a long distance, e.g. when companies operating private networks in New 8 York, Los Angeles, and Tokyo wished to interconnect their various LANs with the same 9 functionality as if they shared one global private network. The basic VPN concept can be envisioned as encrypted communication between 11 two devices, for example where a first server, as part of one LAN supporting a number of 12 devices wirelessly through RF and wireline connections is connected by a "virtual private 13 network" or VPN comprising encrypted content traversing the VPN tunnel to a second 14 server having wireline connections to desktops, notebooks,, and to other WiFi base station.. In addition to these relatively low bandwidth links, first server may also connects 16 to a supercomputer via a high bandwidth connection. The resulting data communications 17 comprises a sequence of data packets comprising an inner VPN packet embedded within 18 an outer IP packet. In operation, an outer IP packet from server A, specifying a source IP 19 address and source port # is sent to server B at destination IP address and destination port #. This outer IP packet established communications between the first and second servers 21 to form an encrypted tunnel to one another for data to pass within. The VPN payload 22 carried by the outer packet contains a last-mile IP packet, providing direct 23 communication between a terminus device, e.g. a desktop with source IP address "DT" 24 and its corresponding adhoc port #, and another terminus device, e.g. a notebook with source IP address "NB" and its corresponding adhoc port #. Although any 26 communication session can be initiated, in one example a request for a file transfer is 27 performed through the VPN tunnel. 28 To establish this transfer securely using a virtual private network, the VPN tunnel 29 is created and the session initiated before the actual communication is sent. In corporate applications, the VPN tunnel may not be carried over the Internet, but instead often is 31 carried by a dedicated ISP or carrier owning their own fiber and hardware network. This

1 carrier oftentimes enters into an annual or long-term contractual agreement with the 2 company requiring VPN services to guarantee a specific amount of bandwidth for a given 3 cost. Ideally, server-to-server communication occurs over a high-speed dedicated link 4 connects directly with no intermediate or "last-mile" connections to disturb the VPN's performance, QoS, or security. 6 In operation, traditional VPNs require a two-step process - one to create or 7 "login" to the VPN, and a second step to transfer data within the secure pipe or tunnel. 8 The concept of tunneling can be envisioned hierarchically as outer IP packets carried by 9 7-layer communication stacks (used for carrying the VPN connection) comprising Layers 1 through Layers 4, where Layer 5 is used to create a virtual VP session 723, and where 11 Layer 6, the presentation layer, is used to facilitate encryption required to form a VPN 12 gateway-to-gateway pipe between servers. While the VPN connection employs Internet 13 Protocol to send the IP packets, the VPN's PHY Layer 1 and VPN data link Layer 2 is 14 often supported by a dedicated carrier to minimize unpredictable routing over the Internet. Application Layer 7 data transferred as device-to-device communication 16 between communicating desktops for example, is delivered as tunneled data including all 17 seven OSI layers needed to establish communication as if the VPN were not present. In 18 this manner the VPN may be envisioned as a communication protocol operating within 19 Layer-7 used to carry VPN inner packets. In operation, outer IP packet once passed from one communication stack to 21 another is opened to reveal encapsulated data, the true message of the packet. In this way, 22 the end-to-end communication occurs ignorant of the details used to create the VPN 23 tunnel, except that the VPN tunnel must be formed in advance of any attempt to 24 communicate and must be closed after the conversation is terminated. Failure to open the VPN tunnel first will result in the unencrypted transmission of an IP packet susceptible to 26 IP packet sniffing, hijacking, infection and more. Failure to close the VPN after a 27 conversation is complete, may provide a cybercriminal the opportunity to hide their 28 illegal activity within someone else's VPN tunnel, and if intercepted, may result in 29 possible criminal charges levied against an innocent person. While VPNs are common ways for multiple private local area networks to 31 interconnect to one another using private connections with dedicated capacity and

1 bandwidth, the use of VPNs over public Networks and the Internet is problematic for two 2 party communications. One issue with VPNs is the VPN connection must be established 3 in advance, before it can be used, not on a packet-by-packet basis For example, in a VoIP 4 call connected over a packet-switched network, before a cell phone can contact the intended call recipient at a second cell phone, it must first establish a VPN session. To do 6 so, the caller's cell phone must first be loaded with VPN connection application. The 7 caller then must send IP packets to VPN host, typically a service provider. These packets 8 are carried through any available last-mile routing, e.g. radio communication from the 9 cell phone to a nearby WiFi base station, followed by wireline communication to a local router, then by wireline communication to the VPN host. Once the session between the 11 caller's cell phone and VPN host is established, the caller's cell phone must then instruct 12 the VPN host to create a VPN tunnel from the caller's cell phone to the VPN host. This 13 leg of the VPN tunnel is facilitated as a Layer 5 session with the tunnel encrypted by 14 Layer 6. Once the VPN connection is set up, then the caller's cell phone may then place a 16 call via any VoIP phone app to any other phone. If the phone being called is not 17 connected to the same VPN, the application must establish a "call out" link over the last 18 mile from the VPN host nearest to the destination cell phone, i.e. the person being called. 19 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 21 5 session between calling and destination cell phones confirming the IP test packets are 22 properly decrypted and intelligible. 23 To place a call the call necessarily comes from a Layer 7 application running on 24 the caller's phone, i.e. a cell phone app using the carrier's data plan, and not from the phone's normal dialup functions, because the telephonic carrier's SIM card in the phone 26 is not compatible with the VPN tunnel. Once the call is initiated, the caller's cell phone 27 transmits a succession of IP packets representing small pieces or "snippets" of sound in 28 accordance with its communication application. These packets are sent from the 29 application in caller's cell phone through the network, e.g. through a WiFi link to a nearby WiFi base station then through a wireline connection to a router, and finally 31 through wireline connection to the VPN host. The data is then sent securely to the VPN

1 host through a VPN tunnel to the terminus device of the VPN network, the destination 2 VPN gateway. In this example the VPN tunnel doesn't extend all the way to the 3 destination cell phone, but instead stops short of device being called. Beyond the VPN's 4 destination gateway, the data is no longer encrypted because the VPN carrier is no longer involved. For data packets leaving the VPN tunnel, VPN host forewords the data onward 6 over the last mile connection of the destination device, e.g. a wireline connection to a 7 nearby router, then by wireline connection to the local cell phone system and tower, 8 transmitting the call as a normal cellular phone call using 2G, 3G or 4G telephony. The 9 process of calling from a cell phone app to a phone not running the same app is called a "call out" feature. 11 The foregoing example highlights another problem with connecting to a VPN 12 over a public network - the last-mile link from the VPN host to the person being called 13 are not part of the VPN, and therefore do not guarantee security, performance or call 14 QoS. Specifically the caller's last mile comprising connections are all open to sniffing and subject to cyber-assaults. Once the call is completed and the caller's cell phone 16 hangs up, the VPN link must be terminated whereby VPN Layer 5 coordinates closing 17 the VPN session and the caller's cell phone disconnects from VPN host. 18 The adaptation of the virtual private network, a technology originally created for 19 computer-to-computer data transfers, suffers several major issues. • Last mile communication from the destination VPN gateway to the 21 destination cell phone is not secure and is at risk for sniffing and surveillance. 22 • The last mile communication between the caller's cell phone and 23 the VPN gateway is secure only if the caller uses a data communication based 24 app. If the caller connects to the VPN gateway using a telephonic link, i.e. a dial in feature, then last mile communications from a caller's cell phone to the nearest 26 VPN gateway is not secure and is at risk for sniffing and surveillance. 27 • The call can only be secured end-to-end if both parties employs 28 data communication and not telephony over their respect last mile links and 29 provided that both parties know to join the same VPN prior to initiating the call. The last bullet point highlights the paradox of secure VPN communication - the 31 person being called needs to know they are being called before they are called in order to

1 join the network. To inform the person they are being to be called, they must first be 2 contacted and instructed to log into the VPN before the call can commence. In essence 3 they must receive an un-secured phone call to connect to a secure phone call. The 4 unsecured phone call is easily hacked, sniffed, and surveiled. Moreover, the metadata of the unsecured call exposes who is calling who is being called, and what time the call 6 occurs. Call metadata is extremely useful in tracking a person's activity or to profile them 7 as a target for criminals. 8 Even ignoring the security concerns, there is no guarantee that placing a call or 9 sending documents through a VPN may not fail for any number of other reasons including: 11 • The VPN may not operate with sufficient low latency to support 12 real-time applications, VoIP or video; 13 • The VPN last-mile connection from the caller to the VPN gateway 14 or from the VPN gateway to the call recipient may not operate with sufficient low latency to support real-time applications, VoIP or video; 16 • The nearest VPN gateway to the caller or to the intended recipient, 17 i.e. "the last mile" may be very far away, possibly even farther than the distance 18 to the call recipient without the VPN, exposing the connection to excessive 19 latency, network instability, uncontrolled routing through unknown networks, variable QoS, and numerous opportunities for man-in-middle attacks in the 21 unprotected portion of the connection; 22 • The VPN last-mile connection from the VPN gateway to the call 23 recipient may not support "call out" connections and packet forwarding or support 24 links to local telcos; • Local carriers or government censors may block calls or 26 connections into or out of known VPN gateways for reasons of national security 27 or regulatory compliance; 28 • Using corporate VPNs, VoIP calls may limited to and from only 29 company employees and specified authorized users, financial transactions and video streaming may be blocked, private email to public email servers such

1 Yahoo, Google, etc. may be blocked, and numerous web sites such YouTube, chat 2 programs, or Twitter may be blocked as per company policy. 3 • In cases of unstable networks, a VPN may get stuck open and 4 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 6 expensive connection fees. 7 Comparing Networks - Comparing communication offered by "over-the top" or 8 OTT providers, to that of communication systems employing public networks to connect 9 to an ad hoc VPN, quickly reveals that aside from the VPN link itself, the majority of both communication systems have nearly identical components and connections. 11 Specifically, the last mile of the caller comprising a cell phone WiFi radio connection, 12 WiFi base station, wireline connections, and router represent the same last-mile 13 connectivity in both implementations. Similarly, on the last mile of the other party, the 14 caller's cell phone, cell phone connection, cell base station and tower, wireline connections, and router are identical for both Internet and VPN versions. The main 16 difference is that in a public network, the VPN tunnel offering secure communication 17 between VPN hosts is replaced by server/routers carrying insecure communication 18 throughout the cloud. Another difference is in OTT communications, the call is instantly 19 available, and where using a VPN extra steps are required to set up the VPN and to terminate the VPN session prior to and following the call. 21 In both examples, the last-mile connections offer unpredictable call QoS, 22 exposure to packet sniffing, and the risk of cyber-assaults. Because server/routers 23 carrying a call are likely managed by different ISPs in different locales, one can interpret 24 the servers as existing different clouds. For example the publically open networks owned and operated by Google, Yahoo, Amazon, and Microsoft may be considered as different 26 clouds, e.g. the "Amazon cloud" even though they are all interlinked by the Internet. 27 A competing network but less popular topology, the peer-to-peer network or PPN, 28 comprising a network made of a large number of peers with packet routing managed by 29 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, 31 costs, and regulation of Internet service providers. When sued by the U.S. government

1 regulators for music copyright violations, the progenitors of Napster jumped ship, 2 invading the early OTT carrier Skype. At that time, Skype's network converted from a 3 traditional OTT into a Napster-like PPN. 4 In PPN operation, every device that makes a login connection to the PPN becomes one more node in the PPN. For example if in one geography, a cell phone with 6 PPN software installed logs into the peer-to-peer network, it like all the other connected 7 devices in the region becomes part of the network. Calls placed by any devices hops 8 around from one device to another to reach is destination, another PPN connected device. 9 For example, if a caller's cell phone uses its PPN connection to call another PPN connected device, e.g. destination cell phone, the call follows a circuitous path through 11 any device(s) physically located in the PPN between the two parties. For example, the 12 call emanating from a caller's cell phone connects by WiFi through a local WiFi base 13 station to a nearby desktop, then to another person's notebook, to a different desktop, 14 onto another desktop, and finally to the destination cell phone through a local cell phone base station and tower. In this manner all routing was controlled by the PPN and the 16 Internet was not involved in managing the routing. Since both parties utilize, the PPN 17 software used to connect to the network also acts as the application for VoP based voice 18 communication. 19 In the case where a cell phone 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, 21 especially to send packets across oceans or mountain ranges. The first part of the routing 22 in the local geography proceeds in a manner similar to the prior example, starting from 23 the caller's cell phone and routed through a WiFi base station, desktop, notebook, more 24 desktops, and so on. At this point, if the nearest notebook is connected to the network, the call will be routed through it, otherwise the call must be routed through a local cell phone 26 base station and tower to the destination cell phone, and then back to cell phone base 27 station and tower before sending it onwards. 28 If the call is transpacific, then computers and cell phones cannot carry the traffic 29 across the ocean so the call is then necessarily routed up to the Internet to 3 rd party server/router in a hosted cloud and onward through connections to 3 rd party server/routers 31 in a different cloud. For example, as it approached its destination, the call then leaves the

1 Internet and enters the PPN in the destination geography first through a desktop which 2 in turn connects to WiFi, to a notebook, and to a base station. Since WiFi does not run the 3 PPN app, the actual packet entering WiFi must travel to either a tablet or cell phone in 4 the WiFi subnet and back to WiFi before being sent on to cell phone base station and tower via a wireline connection. Finally, the caller cell phone call connects to the 6 destination cell phone, which is not a PPN enabled device. The connection thereby 7 constitutes a "call out" for the PPN because it exits PPN network. Using this PPN 8 approach, like a VPN, placing a call involves first registering a calling device to the PPN 9 network by completing a PPN login. Thereafter, the call can be placed using the PPN app. The advantage of the PPN approach is little or no hardware is needed to carry a call 11 over a long distance, and that since every device connected to the PPN regularly updates 12 the PPN operator as to its status, loading and latency, the PPN operator can decide a 13 packet's routing to best minimize delay. 14 The disadvantages of such an approach is that packets traverse a network comprising many unknown nodes representing a potential security threat and having an 16 unpredictable impact on call latency and call QoS. As such, except for Skype, peer-to 17 peer networks operating at Layer-3 and higher are not commonly employed in packet 18 switched communication networks. 19 A comparative summary of adhoc VPN providers, Internet OTT providers, and PPN peer networks is contrasted below. 21

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

Provider Dependent Provider PPN Dependent Bandwidh BandidthDependent 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 VoTP QoS Variable to Good Variable Variable Cloud Security Encrypted Payload Only Unencrypted Unencrypted Last-Mile Unencrypted Unencrypted Unencrypted Security

Sniffable Packet Header (Cloud) Entire Packet Entire Packet Entire Packet (Last Mile) 1 2 As shown, while VPN and the Internet comprise fixed infrastructure, the nodes of 3 a peer-to-peer network vary depending on who is logged in and what devices are 4 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 6 mountain ranges, is contractually guaranteed only in the case of VPNs, and is otherwise 7 unpredictable. The last-mile bandwidth is local provider dependent for both Internet and 8 VPN providers but for PPN is entirely dependent on who is logged in. 9 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 11 instead depends on local telco or network providers, while PPNs have limited ability 12 using best efforts to direct traffic among the nodes that happen to be online at the time in 13 a particular geography. Likewise, for network stability, PPNs have the ability to reroute 14 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 16 necessarily in a timely manner. Network stability for an ad hoc VPN depends on the 17 number of nodes authorized to connect to the VPN host. If these nodes go offline, the 18 VPN is crippled. 19 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 21 complex login procedure. Moreover, most users consider OTT's use of phone numbers 22 rather than separate login IDs used by VPNs and PPNs as a major beneficial feature in 23 ease of use. All three networks listed suffer from variable VoP QoS, generally lagging 24 far behind commercial telephony carriers.

1 From a security point of view, all three options are bad with the last mile 2 completely exposed to packet sniffing with readable addresses and payloads. VPNs offer 3 encryption of the cloud connection but still expose the IP addresses of the VPN hosts. As 4 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 6 protocol or as an embedded portion of the Layer 7 application itself. 7 Overreliance on Encryption - Regardless of whether used for encrypting IP 8 packets or establishing VPNs, today's network security relies almost solely on encryption 9 and represents one weakness in modern packet-switched based communication networks. For example, numerous studies have been performed on methods to attack RSA 11 encryption. While limiting the prime numbers to large sizes greatly reduces the risk of 12 breaking the decryption D-key code using brute force methods, polynomial factor 13 methods have been successfully demonstrated to crack keys based on smaller prime 14 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 16 reasonable cyber-assault times. 17 To combat the ever-present risk of code breaking, new algorithms and "bigger 18 key" encryption methods such as the "advanced encryption standard" or AES cipher 19 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 21 substitution and permutation using different key and block sizes. In its present 22 incarnation, the algorithm comprises fixed block sizes of 128 bits with keys comprising 23 varying lengths of 128 bits, 192 bits, and 256 bits, with the corresponding number of 24 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 26 either software or hardware for any size of key. In cryptography vernacular, an AES 27 based encryption using a 256b key is referred to as AES256 encryption. AES512 28 encryption employing a 512b key is also available. 29 While each new generation raises the bar in cryptography to make better encryption methods and to more quickly break them, profit-minded cybercriminals often 31 concentrate on their targets rather than simply using computing to break an encrypted

1 file. As described previously, using packet sniffing and port interrogation, a cyber pirate 2 can gain valuable information about a conversation, a corporate server, or even a VPN 3 gateway. By cyber-profiling, it may be easier to launch a cyber-assault on a company's 4 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 6 spyware upon opening an embedded link completely circumvent firewall security 7 because they enter the network from "inside" where employees necessarily must connect 8 and work. 9 The chance of breaking encryption also improves if data moves through a network without changing, i.e. statically. In the network of FIG. 1, for example, the underlying 11 data in packets 790, 792, 794 and 799 remain unchanged as the packets move through the 12 network. Each data packet shown comprises a sequence of data or sound arranged 13 sequentially in time or pages unaltered from its original order when it was created. If the 14 content of a data packet is textual, reading the unencrypted plaintext file in the sequence 1A-iB-iC-iD-1E-iF will result in "legible" text for communique number "1". If the 16 content of a data packet is audio, converting, i.e. "playing", the unencrypted plaintext file 17 in the sequence 1A-iB-iC-iD-1E-F through a corresponding audio CODEC, essentially 18 a software based D/A converter, will result in sound for audio file number "1". 19 In either case, throughout this disclosure, each data slot represented by fixed size boxes comprises a prescribed number of bits, e.g. two bytes (2B) long. The exact number 21 of bits per slot is flexible just so long as every communication node in a network knows 22 what the size of each data slot is. Contained within each data slot is audio, video, or 23 textual data, identified in the drawings as a number followed by a letter. For example, as 24 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 26 data in communication #1. Similarly, the second slot of data packet 790 contains the 27 content lB where the number "1" indicates it is part of the same communication #1 and 28 the letter "B" represents the second piece of the data in communication #1, sequentially 29 following 1A. If, for example, the same data packet hypothetically included content "2A" the 31 data represents the first packet "A" in a different communication, specifically for

1 communication #2, unrelated to communication #1. Data packets containing 2 homogeneous communications, e.g. where all the data is for communication #1 are easier 3 to analyze and read than those mixing different communications. Data arranged 4 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. 6 Moreover, in the example shown, since the packet's source and destination IP 7 addresses remain constant, i.e. where the packets remain unchanged during transport 8 through the network in the same form as the data entering or exiting gateway servers 21A 9 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 11 conversation. The simple transport and one-dimensional security, i.e. relying only on 12 encryption for protection, increases the risk of a cyber-attack because the likelihood of 13 success is higher in such overly simplified use of the Internet as a packet-switched 14 network. Securing Real-time Networks And Connected Devices 16 In order to improve the quality of service (QoS) of telephonic, video, and data 17 communication while addressing the plethora of security vulnerabilities plaguing today's 18 packet-switched networks, a new and innovative systemic approach to controlling IP 19 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 21 inventive packet-switched network include the following criteria: 22 1. Insure the security and QoS of a global network or long-distance 23 carrier including dynamically managing real-time voice, video, and data traffic 24 routing throughout a network; 2. Insure the security and QoS of the "local network or telco" in the 26 last mile of the communication network; 27 3. Insure the security and QoS of the "last link" of the 28 communication network, including providing secure communication over 29 unsecuredlines; 4. Insure the security of communicating devices and authenticate 31 users to prevent unauthorized or fraudulent access or use;

1 5. Facilitate a secure means to store data in a device or online in 2 network or cloud storage to prevent unauthorized access; 3 6. Provide security and privacy protection of all non-public personal 4 information including all financial, personal, medical, and biometric data and records; 6 7. Provide security and privacy protection of all financial transactions 7 involving online banking and shopping, credit cards, and e-pay; and 8 8. Provide security, privacy, and as-required, anonymity, in 9 transactional and information exchange involving machine-to-machine (M2M), vehicle-to-vehicle (V2V), and vehicle-to-infrastructure (V2X) communication. 11 Of the above stated goals, the inventive matter contained within this disclosure 12 relates to the second topic described in item # 2, i.e. to "the security and QoS of the local 13 network or telco in the last mile of the communication network" This topic can be 14 considered as secure last mile connectivity without sacrificing real-time communication performance. 16 Glossary 17 Unless the context requires otherwise, the terms used in the description of the 18 Secure Dynamic Communication Network And Protocol have the following meanings: 19 Anonymous Data Packets: Data packets lacking information as to their original origin or final destination. 21 Client or Client Device: A device, typically a cell phone, tablet, notebook, 22 desktop, or IoT device connected to an SDNP Cloud over a Last Mile. 23 Concealment: The encoding process by which the contents of a SDNP packet or 24 portions thereof are rendered unrecognizable using any sequential combination of security operation such as scrambling, splitting, junk data insertions, and encryption. 26 Recovery of concealed data requires execution of the anti-function or decoding processes 27 in reverse order, e.g. decryption, junk data removal, mixing and unscrambling. 28 Decryption: A mathematical operation used to convert data packets from 29 ciphertext into plaintext. Disaggregated Data Storage: The process of fragmenting data files and concealing 31 their content before storing the various fragmented files on different data storage nodes.

1 DMZ Server: A computer server not accessible directly from the SDNP network 2 or the Internet used for storing selectors, seed generators, key generators and other shared 3 secrets. A DMZ may also be referred to as an "air gapped" server, i.e. a computer with no 4 wired network connection or access. Dynamic Encryption / Decryption: Encryption and decryption relying on keys that 6 change dynamically as a data packet traverses the SDNP network. 7 Dynamic Mixing: The process of mixing where the mixing algorithms (the 8 inverse of splitting algorithms) change dynamically as a function of a seed based on a 9 state, such as the time, state, and zone when a mixed data packet is created. Dynamic Scrambling / Unscrambling: Scrambling and unscrambling relying on 11 algorithms that change dynamically as a function of a state, such as the time when a data 12 packet is created or the zone in which it is created. 13 Dynamic Splitting: The process of splitting where the splitting algorithms change 14 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. 16 Encryption: A mathematical operation used to convert data packets from plaintext 17 into ciphertext. 18 Fragmented Data Transport: The routing of split and mixed data through the 19 SDNP network. Junk Data Deletions (or "De-junking"): The removal of junk data from data 21 packets in order to restore the original data or to recover the data packet's original length. 22 Junk Data Insertions (or "Junking"): The intentional introduction of meaningless 23 data into a data packet, either for purposes of obfuscating the real data content or for 24 managing the length of a data packet. Key: A disguised digital value that is generated by inputting a state, such as time, 26 into a key generator which uses a secret algorithm to generate the key. A key is used to 27 select an algorithm for encrypting or decrypting the data in a packet from a selector. A 28 key can be used to safely pass information regarding a state over public or unsecure lines. 29 Key Exchange Server: A computer server, often third party hosted and independent of the SDNP network operator, used to distribute public encryption keys to 31 clients, and optionally to servers using symmetric key encryption, especially for client

1 administered key management, i.e. client based end-to-end encryption to prevent any 2 possibility of network operator spying. 3 Last Link: The network connection between a Client's device and the first device 4 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. In the case of Ethernet 6 communication, the Last Link comprises a physical "tethered" (i.e. wired) connection to 7 a cable modem or optical fiber modem. For WiFi connectivity (e.g. in a caf6), the Last 8 Link comprises a WiFi router connected to a DSL, cable, or fiber network. In a cellular 9 network, the Last Link comprises the radio link between the cellular tower and the mobile phone, which may comprise, for example a 3G or 4G/LTE connection. 11 Last Mile: The network connection between a Client and a gateway media node in 12 an SDNP or other type of network or cloud, including the Last Link. The Last Mile 13 typically comprises communication over networks owned and operated by local telco's 14 and cable companies, e.g. Comcast cable, Verizon cellular, Korean Telecom, British Telecom, etc. 16 Mixing: The combining of data packets from different sources, which may 17 include different data types, to produce one longer data packet (or a series of smaller sub 18 packets) having unrecognizable content. In some cases previously split data packets are 19 mixed to recover the original data content. The mixing operation may also include junk data insertions and deletions and parsing. 21 Multiple PHY or Multi-PHY: Communication involving alternating transport of 22 related sequential data packets over multiple physical mediums, e.g. optical fiber and 4G, 23 different WiFi channels and frequencies, 4G and WiFi, Ethernet WiFi, etc. 24 Parsing: A numerical operation whereby a data packet is broken into shorter sub packets for storage or for transmission. 26 Router: A device that directs the routing of a datagram to the destination address 27 specified in its IP header. For packet routing outside of the SDNP network, the IP address 28 employed may represent a valid Internet IP address (one recognized by a DNS server) or 29 may represent the NAT address assigned by a network address translator operated by the local network provider (e.g. Comcast assigns its own internal IP addresses for 31 communication within the Comcast cable/fiber network).

1 Scrambling: An operation wherein the order or sequence of data segments in a 2 data packet is changed from its natural order into an unrecognizable form. 3 Splitting: An operation wherein a data packet (or a sequence of serial data 4 packets) is split into multiple sub-packets, which are routed to multiple destinations. A splitting operation may also include junk data insertions and deletions. 6 SoftSwitch: Software comprising executable code performing the function of a 7 telecommunication switch and router. 8 SDNP: An acronym for "Secure Dynamic Communication Network and 9 Protocol" meaning a hyper-secure communications network made in accordance with this invention. 11 SDNP Address: An address used for routing SDNP packets through the SDNP 12 cloud or over the Last Mile comprising the ad hoc IP address of the next destination 13 device, i.e. only enough information to execute a single hop. 14 SDNP Administration Server: A computer server used to distribute executable code and shared secrets to SDNP servers globally or in specific zones. 16 SDNP Bridge Node: A SDNP node connecting one SDNP Zone or Cloud to 17 another SDNP Zone or Cloud having dissimilar security credentials. 18 SDNP Client or Client Device: A network connected device, typically a cell 19 phone, tablet, notebook, desktop, or IoT device running a SDNP application in order to connect to an SDNP Cloud, generally connecting over a Last Mile. 21 SDNP Cloud: A network of interconnected SDNP Servers running SoftSwitch 22 executable code to perform SDNP Communications Node operations. 23 SDNP Gateway Node: A media node connecting an SDNP Cloud to a Client 24 Device via a Last Mile. SDNP Gateway nodes require access to at least two Zones - that of the SDNP Cloud and of the Last Mile. 26 SDNP Media Node: SoftSwitch executable code that processes incoming data 27 packets with particular identifying tags in accordance with instructions from the signaling 28 server or another computer performing the signaling function, including encryption /

29 decryption, scrambling / unscrambling, mixing / splitting, tagging and SDNP header and sub-header generation. An SDNP Media Node is responsible for identifying incoming

1 data packets having specific tags and for forwarding newly generated data packets to 2 their next destination. 3 SDNP Media Server: A computer server hosting a SoftSwitch performing the 4 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 6 single-channel communications. 7 SDNP Name Server: A computer server hosting a SoftSwitch performing the 8 functions of a SDNP Name-Server Node in tri-channel communications. 9 SDNP Name Server Node: SoftSwitch executable code that manages a dynamic list of every SDNP device connected to the SDNP cloud. 11 SDNP Network: The entire hyper-secure communication network extending from 12 client-to-client including last link and last mile communication, as well as the SDNP 13 cloud. 14 SDNP Node: A SDNP communication node comprising a software-based "SoftSwitch" running on a computer server or alternatively a hardware device connected 16 to the SDNP network, functioning as an SDNP node, either as Media Node, a Signaling 17 Node, or a Name Server Node. 18 SDNP Server: A computer server comprising either a SDNP Media Server, a 19 SDNP Signaling Server, or a SDNP Name Server and hosting the applicable SoftSwitch functions to operate as an SDNP node. 21 SDNP Signaling Node: SoftSwitch executable code that initiates a call or 22 communication between or among parties, determines all or portions of the multiple 23 routes for fragmented data transport based on caller criteria and a dynamic table of node 24 to-node propagation delays, and instructing the SDNP media how to manage the incoming and outgoing data packets. 26 SDNP Signaling or Signal Server: A computer server hosting a SoftSwitch 27 performing the functions of a SDNP Signaling Node in dual-channel and tri-channel 28 SDNP communications, and also performing the duties of the SDNP Name-Sever Node 29 in dual-channel communications. SDNP Tag: A source address, SDNP zip code, or any other code used to identify 31 an incoming data packet or a sub-packet thereof

1 Security Operation: The process of modifying a data packet to perform 2 concealment (or to recover the content of a concealed packet) using the state-dependent 3 security credentials related to the zone and state of the where the packet is created. 4 Security Settings or Security Credentials: Digital values, such as seeds and keys, that are generated by seed generators or key generators using secret algorithms in 6 conjunction with a constantly changing input state, such as network time, and that can 7 therefore be safety transmitted over public or insecure lines. 8 Seed: A disguised digital value that is generated by inputting a state, such as time, 9 into a seed generator, which uses a secret algorithm to generate the seed. A seed is used to select an algorithm for scrambling, encrypting or splitting the data in a packet from a 11 selector. A seed can be used to safely pass information regarding a state over public or 12 unsecure lines. 13 Selector: A list or table of possible scrambling, encryption or splitting algorithms 14 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, 16 splitting or mixing a packet or packets. 17 Shared Secrets: Confidential information regarding SDNP node operation, 18 including tables or selectors of scrambling /unscrambling, encryption / decryption, and 19 mixing / splitting algorithms, as well as the algorithms used by seed generators, key generators, zone information, and algorithm shuffling processes stored locally on DMZ 21 servers not accessible over the SDNP network or the Internet. 22 Single PHY: Communication of related data packets transported over a single 23 physical medium, e.g. exclusively over optical fiber, or Ethernet, or WiFi, or a cellular 24 network. State: An input, such as location, zone, or network time that is used to 26 dynamically generate security settings such as seeds or keys or to select algorithms for 27 specific SDNP operations such as mixing, splitting, scrambling, and encryption. 28 Time: The universal network time used to synchronize communication across the 29 SDNP network

1 Unscrambling: A process used to restore the data segments in a scrambled data 2 packet to their original order or sequence. Unscrambling is the inverse function of 3 scrambling. 4 Zone: A network of specific interconnected servers sharing common security credentials and shared secrets. Last mile connections comprise separate zones from those 6 in an SDNP Cloud. 7 Secure Dynamic Communication Network And Protocol (SDNP) Design 8 To prevent cyber-assaults and hacking of packet-switched communication while 9 minimizing real-time packet latency, insuring stable call connectivity, and delivering the highest integrity of voice communication and video streaming, the disclosed secure 11 dynamic communication network and protocol, or SDNP, is designed based upon a 12 number of guiding principles including: 13 • Real-time communication should always occur using the lowest 14 latency path. • Unauthorized inspection or sniffing of a data packet should 16 provide no context as to where the packet came from, where it is going, or what is 17 in it. 18 • Data packet payloads should be dynamically re-encrypted, i.e., 19 decrypted and then encrypted again using a different encryption algorithm, with no risk of being hacked in any reasonable time. 21 • Even after they have been decrypted, data packet payloads may 22 still contain incomprehensible payloads comprising a dynamically scrambled mix 23 of multiple conversations and unrelated data mixed with junk packet fillers. 24 Implementation of the above guidelines involves a variety of unique methods, functions, features and implementations including in various embodiments some or all of 26 the following 27 • The SDNP employs one or more dedicated clouds comprising 28 telco, i.e. telecommunication system, soft-switch functions realized using 29 proprietary command and control software not accessible through the Internet. • All intra-cloud communication occurs using dedicated SDNP 31 packet routing within proprietary clouds based on SDNP addresses and dynamic

1 ports (i.e. proprietary NAT addresses), not on DNS recognized IP addresses. 2 SDNP addresses are not usable or routable over the Internet or outside the SDNP 3 cloud. 4 • The SDNP network constantly identifies and dynamically routes all real-time communication through the lowest latency paths available. 6 • No secure or real-time communication is routed outside the SDNP 7 cloud or over the Internet except in cloud-to-cloud and last-mile communication, 8 and then generally using single-hop routing with invisible addresses. 9 • Routing data contained within a data packet identifies the routing for a single hop between two adjacent devices, identifying only the last and next 11 server's SDNP or IP addresses 12 • The phone number or IP addresses of the caller and the call 13 recipient, i.e. the clients' respective source and destination addresses, are not 14 present in the IP packet headers nor are they present in the encrypted payload • Command and control related shared secrets exist in system 16 software installed in secure DMZ servers not accessible through the Internet. 17 • SDNP packet communication may occur through three 18 independent channels - a "name server" used to identify elements within the 19 SDNP cloud, "media servers" used for routing content and data, and "signaling servers" used for packet and call command and control. 21 • Routing information, along with keys and numeric seeds (as 22 needed) may be supplied to all participating media servers through an 23 independent signaling channel prior to the call or communique and not with 24 content. The signaling server supplies the media servers with only the last and next destination of a packet traversing the network. 26 • Media packets contain fragmented data representing only a portion 27 of a call, document, text or file, dynamically mixed and remixed with other 28 packets containing fragmented data from other sources and of different types. 29 • Special security methods are employed to protect the first- and last-mile communication, including separating signaling server-related 31 communications from media and content-related packets.

1 • Packet transport is content-type dependent, with voice and real 2 time video or streaming based on an enhanced UDP, while signaling packets, 3 command-and-control packets, data files, application files, systems files, and 4 other files which are sensitive to packet loss or latency utilize TCP transport. • Special security and authentication methods are used to confirm 6 that a device is the real client and not a clone, and to authenticate that the person 7 communicating is the true owner of the device and not an imposter. 8 To ensure secure communication with low latency and high QoS in VoIP and 9 real-time applications, the disclosed "secure dynamic communication network and protocol" or SDNP, utilizes an inventive "dynamic mesh" network comprising 11 • Dynamic adaptive multipath and meshed routing with minimal 12 latency 13 • Dynamic packet scrambling 14 • Dynamic fragmentation using packet splitting, mixing, parsing, and junk bit packet fillers 16 • Dynamic intra-node payload encryption throughout a network or 17 cloud 18 • Dynamic network protocol with address disguising and need-to 19 know routing information • Multichannel communication separating media and content from 21 signaling, command and control, and network addresses 22 • Dynamic adaptive real-time transport protocol with data type 23 specific features and contextual routing 24 • Support of client-encrypted payloads with user-key management • Lightweight audio CODEC for high QoS in congested networks 26 As described, SDNP communication relies on multi-route and meshed 27 communication to dynamically route data packets. Contrasting single-path packet 28 communication used for Internet OTT and VoIP communications, in SDNP 29 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 31 caller, but in fragmented form, dynamically mixing and remixing content emanating from

1 multiple sources and callers, where said data agglomerates incomplete snippets of data, 2 content, voice, video and files of dissimilar data types with junk data fillers. The 3 advantage of the disclosed realization of data fragmentation and transport is that even 4 unencrypted and unscrambled data packets are nearly impossible to interpret because they represent the combination of unrelated data and data types. 6 By combining fragmented packet mixing and splitting with packet scrambling and 7 dynamic encryption, these hybridized packets of dynamically encrypted, scrambled, 8 fragmented data comprise meaningless packets of gibberish, completely unintelligible to 9 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. 11 Moreover, each packet's fragmented content, and the secrets used to create it, 12 remain valid for only a fraction of a second before the packet is reconstituted with new 13 fragments and new security provisions such as revised seeds, keys, algorithms, and 14 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 16 thousands of compute years to be processed in one tenth of a second, a challenge twelve 17 orders of magnitudes greater than the time available to break it. 18 The combination of the aforementioned methods facilitates multi-dimensional 19 security far beyond the security obtainable from static encryption. As such, the disclosed secure dynamic communication network and protocol is referred to herein as a 21 "HyperSecure" network. 22 23 Data Packet Scrambling - In accordance with the disclosed invention, secure 24 communication over a packet-switched network relies on several elements to prevent hacking and ensure security, one of which involves SDNP packet scrambling. SDNP 26 packet scrambling involves rearranging the data segments out of sequence, rendering the 27 information incomprehensible and useless. As shown in FIG. 2A, an unscrambled data 28 packet, data packet 923, processed through scrambling operation 924, results in 29 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 31 dynamic variables or numerical seeds based on "states," such as time 920 when the

1 scrambling occurred, and a numerical seed 929 generated by seed generator 921, which 2 may generate seed 929 using an algorithm that is also dependent on a state such as time 3 920 at the time of the scrambling. For example, if each date is converted into a unique 4 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 6 specific scrambling operation 924, chosen from a list of available scrambling methods, 7 i.e. from scrambling algorithms 922. In data flow diagrams, it is convenient to illustrate 8 this packet-scrambling operation and sequence using a schematic or symbolic 9 representation, as depicted herein by symbol 926. The unscrambling operation, shown in FIG. 2B illustrates the inverse function of 11 scrambling operation 924, specifically unscrambling operation 927, where the state or 12 time 920 and corresponding seed 929 used to create scrambled data packet 925 are re 13 used for undoing the scrambling to produce unscrambled data, specifically unscrambled 14 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 16 operation 927 as selected from scrambling algorithm list 922. Although scrambling 17 algorithm list 922 references the term "scrambling", the same algorithm table is used to 18 identify and select the inverse function needed for performing "unscrambling", i.e. 19 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 21 steps performed in reverse order, list 922 could also be renamed as "scrambling /

22 unscrambling" algorithms list 922. For clarity's sake however, the table is labeled only 23 by the function and not by its anti-function. 24 Should the scrambling algorithm selected for implementing unscrambling operation 927 not match the original algorithm employed in packet scrambling, or should 26 seed 929 or state or time 920 not match the time scrambling occurred, then the 27 unscrambling operation will fail to recover the original unscrambled data packet 923, and 28 the packet data will be lost. In data flow diagrams, it is convenient to illustrate this packet 29 unscrambling process and sequence using a schematic or symbolic representation, as depicted herein by symbol 928.

1 In accordance with the disclosed invention, numerous algorithms may be used to 2 perform the scrambling operation so long that the process in reversible, meaning 3 repeating the steps in the opposite order as the original process returns each data segment 4 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 6 function F-1(A) or alternatively a transform has a corresponding anti-function such that 7 F-'[F (A)]= A 8 meaning that a data file, sequence, character string, file or vector A processed by 9 a function F will upon subsequent processing using the anti-function F-1 return the original input A undamaged in value or sequence. 11 Examples of such reversible functions are illustrated by the static scrambling 12 algorithms shown in FIG. 2C including mirroring and phase-shift algorithms. In 13 mirroring algorithms the data segments are swapped with other data segments as a mirror 14 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 16 packet 930 are swapped, i.e. where 1A and 1B are switched in position, as are IC and ID, 17 1E and IF and so on, to produce scrambled output data packet 935, with a line of 18 symmetry centered between the first and second data segments, between the third and 19 fourth data segments, and so on, or mathematically as 1. 5 *, 3.5, 5 .5, , (1.5 + 2n)th position. 21 In mod-3 mirroring, the first and third data segments of every three data segments 22 are swapped while the middle packet of each triplet remains in its original position. 23 Accordingly, data segments 1A and IC are swapped while 1B remains in the center of the 24 triplet, data segments ID and IF 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 26 line of symmetry is centered in the 2d, 5 h, 8 1h... , (2+3n)th position. 27 In mod-4 mirroring, the first and fourth data segments and the second and third of 28 every four data segments are swapped, and so on to produce scrambled output data 29 packet 937 from input data packet 931. Accordingly, data segment 1A is swapped with ID; data segment 1B is swapped with IC; and so on. In mod-4 mirroring, the line of 31 symmetry is centered between the second and third data segments of every quadruplet,

1 e.g. between the 2"d and 3 rd data segments, the 6' and 7' data segments, and so on, or 2 mathematically as 2.5*, 6.5h, . . , (2.5 + 4n)t position. In mod-m mirroring, the mt data 3 segment of input data packet 932 is swapped with the first, i.e. the 0 data segment; the 4 0* data segment is swapped with the m* element; and similarly the n* element is swapped with the (m-n)* data segment to produce scrambled output data packet 938. 6 Another scrambling method also shown in FIG. 2C is a frame-shift, where every 7 data segment is shifted left or right by one, two, or more frames. For example, in a single 8 frame phase shift, every data segment is shifted by one frame, where the first data 9 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 11 data packet 930, frame IF in the example shown, is shifted to the first frame previously 12 occupied by data segment 1A. 13 In a 2-frame phase shift, the first data segment 1A of input data packet 930 is 14 shifted by two frames into the position previously occupied by data segment IC, the 4* frame ID is shifted into the last position of scrambled output data packet 941, the next to 16 the last data segment 1E is shifted into the first position and the last position IF is shifted 17 into the second position. Similarly, in a 4-frame phase shift, the data segments of input 18 data data packet 930 are shifted by four places with first frame 1A replacing the frame 19 previously held by 1E, 1B replacing IF, IC replacing 1A, and so on, to produce scrambled output data packet 942. In the case of the maximum phase shift, the first frame 21 replaces the last, the second frame originally held by 1B becomes the first frame of 22 output data packet 943, the second element is shifted into the first position, the third 23 position into the second place, and so on. Phase-shifting one frame beyond the maximum 24 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 26 for phase shifts-to the left but with different results. 27 The aforementioned algorithms and similar methods as disclosed are referred 28 herein to as static scrambling algorithms because the scrambling operation occurs at a 29 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 31 scrambling shall occur. As illustrated in FIG. 2D, in accordance with the disclosed

1 invention, parametric scrambling means the scrambling method is chosen from a table of 2 possible scrambling algorithms, e.g. sort # A, sort # B, etc., based on a value derived 3 from data contained within the data packet itself. For example, assume each data segment 4 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 6 data segment is to employ the decimal or hexadecimal equivalent of the bit data in the 7 data segment. If the data segment contains multiple terms, the numeric equivalent can be 8 found by summing the numbers in the data segment. The data segment data is then 9 combined into a single number or "parameter" and then used to select which scrambling method is employed. 11 In the example shown, unscrambled data packet 930 is converted parametrically 12 in step 950 into a data table 951, containing a numeric value for each data segment. As 13 shown data segment 1A, the 0 t frame, has a numeric value of 23, data segment 1, the 14 1 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 16 represents the linear summation of all the data segment values from table 951, 17 parametrically totaling 1002. In step 954 this parametric value, i.e. sum 953, is compared 18 against a condition table, i.e. in software a set of predefined if-then-else statements, to 19 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 21 of 1002 falls in the range of 1000 to 1499, meaning that sort # C should be employed. 22 Once the sort routine is selected, the parametric value is then no longer required. The 23 unscrambled data input 930 is then scrambled by the selected method in step 956 to 24 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 26 first data segment of scrambled data packet 959, the 0 t frame is determined by moving 27 the ID data segment to the left by three moves, i.e. a 3 shift. The1 st frame comprises data 28 segment 1B, unchanged from its original position, i.e. a move of 0 places. The 2"d frame 29 comprises 1E, a data segment shifted left by two moves from its original position. The same is true for the 3 rd frame comprising data segment IF shifted left by two moves from 31 its original position. The 4 frame of scrambled data packet output 959 comprises data

1 segment IC shifted right, i.e. +2 moves, from its original position. The 5 frame 2 comprises data segment 1A, shifted five moves to the right, i.e. +5, from its original 3 position. 4 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 6 packet 959. To unscramble the scrambled data packet, the process is reversed, using the 7 same sort method, sort # C. In order to insure that the same algorithm is selected to 8 perform the unscrambling operation, the parametric value 953 of the data packet cannot 9 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 11 value regardless of the order of the numbers. 12 Dynamic scrambling utilizes a system state, e.g. time, to be able to identify the 13 conditions when a data packet was scrambled, enabling the same method to be selected to 14 perform the unscrambling operation. In the system shown in FIG. 2E, the state is used to generate a disguised numerical seed, which is transmitted to the sender or recipient of the 16 package, which then uses the seed to select a scrambling algorithm from a table. 17 Alternatively, the state itself may be transmitted to the sender or recipient, the state may 18 be used by a hidden number generator located in the sender or recipient to generate a 19 hidden number, where the hidden number is used to select a scrambling/unscrambling algorithm. Thus, in FIG. 2E a state, e.g. time 920, is used to generate a hidden number 21 961, using hidden number generator 960, and the hidden number 861a is used to select a 22 scrambling method from scrambling algorithm list 962. Hidden number generator 960 23 also may input the hidden number HN 961b directly to scrambling operation 963, where 24 HN may serve as a variable in executing the scrambling operation. Thereafter, scrambling operation 963 converts unscrambled data packet 930 into scrambled data packet 964.As 26 shown in FIG. 2F, the state 920 may be passed directly to hidden number generator 960 27 or state 920 may be passed to hidden number generator via seed generator 921. 28 The benefit of using a hidden number to select a scrambling algorithm instead of 29 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 31 scrambled data to corresponding numeric seeds. Although the seed may be visible in the

1 data stream and therefore subject to spying, the hidden number generator and the hidden 2 number HN it creates is based on a shared secret. The hidden number HN is therefore not 3 present in the data stream or subject to spying or sniffing, meaning it is not transmitted 4 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 6 thwarting hackers because the purpose of the numeric seed is disguised. 7 Once the algorithm is selected, the numeric seed may also be used as an input 8 variable in the algorithm of scrambling process 963. Dual use of the numeric seed further 9 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 11 similar manner, to unscramble a dynamically scrambled data packet, seed 929 (or 12 alternatively the state or time 920) must be passed from the communication node, device 13 or software initially performing the scrambling to any node or device wishing to 14 unscramble it. In accordance with the disclosed invention, the algorithm of seed generation 921, 16 hidden number generator 960, and the list of scrambling algorithms 962 represent "shared 17 secrets," information stored in a DMZ server (as described below) and not known to 18 either the sender or the recipient of a data packet. The shared secret is established in 19 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 21 insure the secret does not leak. As described below, shared secrets may be limited to 22 "zones" so that knowledge of one set of stolen secrets still does not enable a hacker to 23 access the entire communication network or to intercept real-time communiques. 24 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 26 scramble or unscramble the data. This state on which the seed is based may comprise any 27 physical parameter such as time, communication node number, network identity, or even 28 GPS location, so long as there is no ambiguity as to the state used in generating the seed 29 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 31 part of the shared secrets, and hence knowledge of the seed does not allow one to

1 determine the state on which the seed is based. The seed may be passed from one 2 communication node to the next by embedding it within the data packet itself, by sending 3 it through another channel or path, or some combination thereof. For example, the state 4 used in generating a seed may comprise a random number generated by a counter and subsequently incremented by a fixed number each time a data packet traverses a 6 communication node, with each count representing a specific scrambling algorithm. 7 In one embodiment of dynamic scrambling, during the first instance of scrambling 8 a random number is generated to select the scrambling method used. This random 9 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 11 the next node, the embedded number is read by the communication node and used by the 12 software to select the proper algorithm to unscramble the incoming data packet. The 13 number, i.e. the "count" is next incremented by one count or some other predetermined 14 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 16 number. The next communication node repeats the process. 17 In an alternative embodiment of the disclosed counter-based method for selecting 18 a scrambling algorithm, a random number is generated to select the initial scrambling 19 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 21 embedded in the data packet in a header or portion of the data packet reserved for 22 command and control and not subject to scrambling. The data packet is then forwarded to 23 the next communication node. When the packet arrives at the next communication node, 24 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 26 the packet accordingly. The count is then incremented by one or any predetermined 27 integer, and the count is again stored in the data packet's header or any portion of the data 28 packet reserved for command and control and not subject to scrambling, overwriting the 29 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 31 node, the server then adds the random number shared secret added to the revised counter

1 value extracted from the data packet. This new number uniquely identifies the scrambling 2 algorithm employed by the last communication node to scramble the incoming packet. In 3 this method, only a meaningless count number can be intercepted from the unscrambled 4 portion of a data packet by a cyber-pirate, who has no idea what the data means. In another alternative method, a hidden number may be employed to 6 communicate the state of the packet and what algorithm was employed to scramble it. A 7 hidden number combines a time-varying state or a seed, with a shared secret generally 8 comprising a numeric algorithm, together used to produce a confidential number, i.e. a 9 "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. 11 The hidden number is then used to select the scrambling algorithm employed. Since the 12 state or seed is meaningless without knowing the algorithm used to calculate the hidden 13 number and because the shared-secret algorithm can be stored behind a firewall 14 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 16 also represent a shared secret. In one embodiment, a number carried by an unscrambled 17 portion of a data packet and observable to data sniffing, e.g. 27482567822552213, 18 comprises a long number where only a portion of the number represents the seed. If for 19 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. 21 This seed is then combined with a shared secret algorithm to generate a hidden number, 22 and the hidden number is used to select the scrambling algorithm, varying dynamically 23 throughout a network. 24 The application of scrambling of data packets in a SDNP network is described in U.S. Application No. 14/803,869, filed July 20, 2015, entitled "Secure Dynamic 26 Communication Network and Protocol". The application of data packet scrambling in 27 Last Mile communication will be described in further detail in this disclosure. 28 As described, the data traversing the network, albeit scrambled, can be referred to 29 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 31 comprising the original data, whether scrambled or not, is translated into a meaningless

1 series of nonsense characters using an encryption key, and cannot be restored to its 2 original plaintext form without a decryption key. The role of encryption in the disclosed 3 SDNP based communication is discussed further in the following section on 4 "Encryption." In order to change the sequence of data packets during transport through the 6 network, packet "re-scrambling" is required, as shown in FIG. 3. The process of packet 7 re-scrambling returns a scrambled data packet to its unscrambled state before scrambling 8 it again with a new scrambling algorithm. Thus, the term "re-scrambling" as used herein, 9 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 11 could occur by scrambling a previously scrambled package and losing track of the 12 sequence needed to restore the original data. As shown, once initially scrambled by 13 packet scrambling operation 926, scrambled data packet 1008 is "re-scrambled," first by 14 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 16 anew with scrambling operation 926, using a different scrambling algorithm than used in 17 the prior scrambling operation 926. The resulting re-scrambled data packet 1009 differs 18 from the prior scrambled data packet 1008. Re-scrambling operation 1017 comprises the 19 successive application of unscrambling followed by scrambling, referred to herein as "US re-scrambling," where "US" is an acronym for "unscrambling-scrambling." To recover 21 the original data packet 930, the final packet unscrambling operation 928 requires using 22 the inverse function of the same algorithm used to last re-scramble the data packet. 23 In accordance with the disclosed invention, the static and dynamic scrambling of 24 data renders interpretation of the unscrambled data meaningless, reordering sound into unrecognizable noise, reordering text into gibberish, reordering video into video snow, 26 and scrambling code beyond repair. By itself, scrambling provides a great degree of 27 security. In the SDNP method disclosed herein, however, scrambling is only one element 28 utilized to provide and insure secure communication free from hacking, cyber-assaults, 29 cyber-piracy, and man-in-the-middle attacks. Packet Encryption - In accordance with the disclosed invention, secure 31 communication over a packet-switched network relies on several elements to prevent

1 hacking and ensure security, one of which involves SDNP encryption. As described 2 previously, encryption from the Greek meaning "to hide, to conceal, to obscure" 3 represents a means to convert normal information or data, commonly called "plaintext", 4 into "ciphertext" comprising an incomprehensible format rendering the data unreadable without secret knowledge. In modem communication, this secret knowledge generally 6 involves sharing one or more "keys" used for encrypting and decrypting the data. The 7 keys generally comprise pseudo-random numbers generated algorithmically. Numerous 8 articles and texts are available today discussing the merits and weaknesses of various 9 encryption techniques such as "Cryptonomicon" by Neal Stephenson © 1999, "The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography" by Simon 11 Singh © 1999, "Practical Cryptography" by Niels Ferguson © 2013, and "Cryptanalysis 12 A Study of Ciphers and Their Solution" first published in 1939. 13 While the concept of encryption or ciphers is ancient and well known to those 14 skilled in the art, the application of cryptography in the disclosed secure dynamic communication network and protocol is unique, facilitating both end-to-end encryption 16 and single-hop node-to-node dynamic encryption to the network architecture itself, 17 independent of any client's own encryption. SDNP communication is architected with the 18 basic precept that given sufficient time, any static encrypted file or message can 19 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 21 proposition because the converse, i.e. waiting till a specific encryption method fails, may 22 result in unacceptable and irreversible consequential damage. 23 Instead, SDNP communication is based on the premise that all encrypted files 24 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 26 dynamically at regular intervals, ideally far more frequently than the best estimates of the 27 time required to crack its encryption with state-of-the-art computers. For example, if it is 28 estimated by cryptologists that a large server farm of crypto-engines can break a given 29 cipher in one year, then in SDNP communication a data packet will be re-encrypted every second or even every lOOms, intervals many orders of magnitude shorter than the best 31 technology's capability to crack it. As such, SDNP encryption is necessarily dynamic, i.e.

1 time variant, and may also be spatially variant, i.e. depending on a communication node's 2 location in a packet-switched network or geography. Thus, as used herein, the terms "re 3 encrypting" or "re-encryption" refer to decrypting a data packet and then encrypting it 4 again, typically with a different encryption algorithm or method. SDNP encryption therefore involves converting data from unencrypted plaintext 6 into ciphertext repeatedly and frequently, rendering the information incomprehensible 7 and useless. Even if a given packet's data encryption is miraculously broken, by 8 employing SDNP's dynamic encryption methods, the next data packet utilizes a 9 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, 11 the potential damage of unauthorized access is mitigated because an exposed data packet 12 contains, by itself, a data file too small to be meaningful or useful by a cyber-pirate. 13 Moreover, by combining dynamic encryption with the aforementioned SDNP scrambling 14 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 16 scrambled into a meaningless and incomprehensible sequence of data segments. 17 To avoid the shelf life security concerns, SDNP encryption is dynamic and state 18 dependent. As shown in FIG. 4A, an unencrypted data packet comprising plaintext 930, 19 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 21 of plaintext 930 is encrypted in toto, treating data segments 1A through IF as a single 22 data file. In the case of ciphertext 1025, each data segment 1A through IF of plaintext 23 930 is encrypted separately and distinctly, and is not merged with other data segments. 24 First data segment 1A is encrypted into a corresponding first ciphertext data segment shown for illustration purposes by a string of characters starting with 7$ and comprising a 26 long string of characters or digits not shown. Similarly, second plaintext data segment 1B 27 is encrypted into second ciphertext data segment comprising a long string of characters 28 shown for illustrative purposes starting with *A. The characters 7$ and *A are meant to 29 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 31 source or the length of the character strings being encrypted.

1 Encryption operation 1020 can use any algorithm, cryptographic, or cipher 2 method available. While the algorithm may represent a static equation, in a one 3 embodiment the encryption operation uses dynamic variables or "states" such as time 920 4 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 6 performed. For example, the date and time of encryption may be used as a numeric seed 7 for generating an encryption key that cannot be recreated even if the encryption algorithm 8 were discovered. Time 920 or other "states" may also be used to select a specific 9 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 11 operation and sequence using a schematic or symbolic representation, as depicted herein 12 by the symbol shown for encryption operation 1026. Throughout this invention 13 disclosure, a padlock may also symbolically represent secure and encrypted data. 14 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 16 specific time, self-destruct and are lost forever. 17 The decryption operation shown in FIG. 4B illustrates the inverse function of 18 encryption operation 1020, specifically decryption operation 1031, where the state or 19 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, 21 i.e. decrypting the file, to produce unencrypted data comprising original plaintext data 22 packet 990. Using the same state or time 920 employed when the packet encryption first 23 occurred, the same encryption operation that was selected from encryption algorithm list 24 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 26 and select the inverse function needed for performing "decryption", i.e. encryption 27 algorithm list 1023 contains the information needed both for encrypting and decrypting 28 data packets. Because the two functions involve the same steps performed in reverse 29 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 31 anti-function.

1 Should the encryption algorithm selected for implementing decryption operation 2 1031 not match the inverse of the original algorithm employed in packet encryption 3 operation 1020, should state or time 920 not match the time encryption occurred, or 4 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 6 unencrypted data 990 and the packet data will be lost. In data flow diagrams, it is 7 convenient to illustrate this packet decryption operation and sequence using a schematic 8 or symbolic representation, as depicted herein by the symbol shown for decryption 9 operation 1032. As described previously in this disclosure, knowledge regarding the use of 11 encryption and decryption keys in cryptography and of common encryption algorithms, 12 such as symmetric public key encryption, RSA encryption, and AES256 encryption 13 among others, are commonplace and well known to those skilled in the art. The 14 application of such well known cryptographic methods in the disclosed SDNP communication system is, however, not readily susceptible to hacking or decryption 16 because of hidden information, shared secrets, and time-dependent dynamic variables and 17 states unique to the disclosed SDNP communication. 18 So even in the unlikely case where a cyber-pirate has sufficient computer power 19 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 21 decryption operation, and must also crack the encryption in a fraction of a second before 22 the encryption changes. Moreover every data packet traversing the disclosed SDNP 23 network utilizes a different encryption method with unique keys and dynamic states. The 24 combination of missing information, dynamic states, and limited informational content contained within any given packet, renders obtaining meaningful data theft from any 26 given data packet both challenging and unrewarding to a cyber-pirate. 27 The application of dynamic encryption and decryption of data packets in a SDNP 28 network is described in the above-referenced U.S. Application No. 14/803,869, entitled 29 "Secure Dynamic Communication Network and Protocol". The application of data packet cryptography in Last Mile communication will be described in further detail in this 31 disclosure.

1 In order to intercept an entire document, video stream, or voice conversation to 2 reconstruct a coherent data sequence, a cyber-assault must successively crack and decrypt 3 not one but thousands of successive SDNP packets. The daunting challenge of 4 continuously hacking a succession of SDNP packets is further exacerbated by combining dynamic encryption with the previously described methods regarding data packet 6 scrambling. As illustrated in FIG. 5, the creation of an encrypted, scrambled data packet 7 1024 involves the successive combination of scrambling operation 926 and encryption 8 operation 1026 to convert un-scrambled plaintext data packet 990 first into scrambled 9 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 11 sequence first by decryption operation 1032 to recover scrambled plaintext data packet 12 1035, then by unscrambling operation 928 to recover unscrambled plaintext data packet 13 990. 14 As shown, scrambling and encryption represent complementary techniques in achieving secure communication. Unencrypted scrambled data traversing the network, is 16 referred to as "plaintext" because the actual data is present in the data packets, i.e. the 17 packets have not been encrypted into ciphertext. Encrypted data packets, or ciphertext, 18 comprise scrambled or unscrambled character strings translated into a meaningless series 19 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 21 employed, the encryption and decryption keys may comprise the same key or distinct 22 keys mathematically related by a predefined mathematical relationship. As such, 23 scrambling and encryption represent complementary techniques in achieving secure 24 communication in accordance with the disclosed invention for SDNP communication. The two methods, scrambling and encryption, can be considered independently 26 even when used in combination, except that the sequence used to restore the original data 27 packet from an encrypted scrambled data packet must occur in the inverse sequence to 28 that used to create it. For example, if the data packet 990 was first scrambled using 29 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 31 decrypted using decryption operation 1032 and then unscrambled using unscrambling

1 operation 928. Mathematically, if a scrambling operation F scrambles a string of bits or 2 characters into an equivalent scrambled version and an unscrambling operation F-1 3 undoes the scrambling, whereby 4 F-'[F(A)]= A and similarly if an encryption operation G encrypts a string of plaintext into 6 equivalent ciphertext and a decryption operation G-1 undoes the encryption whereby 7 G-'[G(A)]= A 8 then in combination, the successive operation of scrambling and then encrypting 9 followed by decrypting and then unscrambling returns the original argument A, the unscrambled plaintext data packet. Accordingly, 11 F- 1 {G-1[G(F (A))]} = A 12 because the sequence occurs in inverse order, specifically decrypting [G-1] 13 encrypted scrambled packet [G(F(A))] restores scrambled plaintext data packet F(A). 14 Subsequent unscrambling operation F-1 of scrambled plaintext packet F(A) restore the original data packet A. 16 Provided linear methods are employed, the sequence is reversible. For example, if 17 the data packet is first encrypted and then scrambled, then to restore the original data 18 packet the scrambled ciphertext must first be unscrambled and then decrypted. 19 Accordingly, G-1 {F-[F(G(A))]} = A 21 Changing the sequence does not work. Decrypting a data packet that was 22 previously encrypted and then scrambled without first unscrambling it will not recover 23 the original data packet, i.e. 24 F-1 {G-1 [F(G(A))]} A Similarly unscrambling a packet that was scrambled and then encrypted will also 26 fail to restore the original data packet, because 27 G-1 {F-[G(F(A))]} A 28 To summarize, if the plaintext packet is scrambled before it is encrypted, it 29 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.

1 While it is understood that scrambling and encrypting may be performed in either 2 sequence, in one embodiment of the SDNP methods in accordance with this invention, 3 encryption and decryption occur more frequently during network transport than 4 scrambling and therefore encryption should occur after scrambling and decryption should occur before unscrambling, as illustrated in FIG. 5, rather than the converse. For 6 convenience, we define the combination of packet scrambling operation 926 followed by 7 encryption operation 1026 as encrypting scrambled packet operation 1041, and its 8 converse, the combination of decryption operation 1032 followed by packet 9 unscrambling operation 928 as unscrambling decrypted packet operation 1042. These hybridized operations may be employed in static and dynamic SDNP communication in 11 accordance with this invention. 12 One means to enhance to enhance security in any implementation using static 13 scrambling encryption is to insure that each data packet sent is subjected to different 14 scrambling and/or encryption methods, including changes in state, seeds, and/or keys at time ti when each data packet enters the communication network. 16 However, a more robust alternative involves dynamically changing a data 17 packet's encryption or scrambling, or both, as the packet traverses the network in time. In 18 order to facilitate the required data processing to realize a fully dynamic version of SDNP 19 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 21 then encrypt) each packet as it passes through each communication node in a packet 22 switched communication network. As used herein the term "re-packet" or "re-packeting" 23 will sometimes be used to refer to the combination of "re-scrambling" and "re 24 encryption," whether the packet is initially decrypted before it is unscrambled or unscrambled before it is decrypted. In either case, the unscrambling and decryption 26 operations at a given node should be performed in an order that is the reverse of the 27 scrambling and encryption operations as the packet left the prior node, i.e., if the packet 28 was scrambled and then encrypted at the prior node, it should first be decrypted and then 29 unscrambled at the current node. Typically, the packet will then be scrambled and then encrypted as it leaves the current node.

1 The "re-packet" operation at a communication node is illustrated in FIG. 6, where 2 an incoming ciphertext data packet 1040 is first decrypted by decryption operation 1032, 3 then unscrambled by unscrambling operation 928 to recover the unscrambled plaintext 4 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 6 the best format in which to perform such operations. The plaintext data packet 990 is then 7 again scrambled using scrambling operation 926 followed by a new encryption 8 performed by encryption operation 1026 to produce a new scrambled ciphertext data 9 packet 1043. Since the re-packet operation of incoming scrambled ciphertext data packet 1040 occurs successively by decryption, unscrambling, scrambling and encryption, the 11 acronym DUSE re-packet operation 1045 is used herein to denote the disclosed technique 12 in accordance with this invention. In a dynamic secure network, the state or time, the 13 decryption key, and any seeds used for performing decryption operation 1032 and 14 unscrambling operation 928 are preferably different than the state or time, seeds or encryption keys used for executing scrambling operation 926 and encryption operation 16 1026. 17 The application of re-packeting of data packets in a SDNP network is described in 18 the above-referenced U.S. Application No. 14/803,869, entitled "Secure Dynamic 19 Communication Network and Protocol". The application of data packet re-packeting in Last Mile communication will be described in further detail in this disclosure. 21 Packet Mixing andSplitting - Another key element of the secure dynamic 22 communication network and protocol disclosed herein is its ability to split data packets 23 into sub-packets, to direct those sub-packets into multiple routes, and to mix and 24 recombine the sub-packets to reconstruct a complete data packet. The process of packet splitting is illustrated in FIG. 7A, where data packet 1054 is split, using splitting 26 operation 1051 combined with algorithmic parse operation 1052 and with junk operation 27 1053, which has the ability to insert or remove non-data "junk" data segments. 28 Analogous to junk DNA present in the human genome, junk data segments are inserted 29 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 31 amount of data to fill a packet. The presence of junk data segments inserted into a data

1 packet also makes it difficult for cyber-pirates to distinguish real data from noise. As 2 used herein, a "junk" packet or data segment is a packet or data segment that consists 3 entirely of meaningless data (bits). These junk bits can be introduced into a stream of data 4 packets obfuscating real data in a sea of meaningless bits. The purpose of parse operation 1052 is to break data packet 1054 into smaller 6 data packets, e.g. data sub-packets 1055 and 1056, for processing of each of the 7 constituent components. Breaking data packet 1054 into smaller pieces offers unique 8 advantages such as supporting multipath transport, i.e. transmitting the data packets over 9 multiple and different paths, and facilitating unique encryption of constituent sub-packets using different encryption methods. 11 The splitting operation can use any algorithm, numerical method, or parsing 12 method. The algorithm may represent a static equation or include dynamic variables or 13 numerical seeds or "states" such as time 920 when the incoming data packet 1054 was 14 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 16 data packet's creation. For example, if each date is converted into a unique number 17 ascending monotonically, then every seed 929 is unique. Time 920 and seed 929 may be 18 used to identify a specific algorithm chosen from a list of available methods, i.e. from 19 algorithm 1050. Packet splitting, or un-mixing, comprises the inverse procedure of mixing, using the same algorithm executed in the precise reverse sequence used 21 previously to create the specific packet. Ultimately everything that is done is undone but 22 not necessarily all in one step. For example, a scrambled encrypted data packet might be 23 decrypted but remain scrambled. Processed by splitting operation 1051, un-split incoming 24 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 26 data flow diagrams, it is convenient to illustrate this packet splitting operation 1051 27 including parsing 1052 and junk operation 1053 using a schematic or symbolic 28 representation, as depicted herein by the symbol shown for splitting operation 1057. 29 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 31 the insertion of junk packets or sub-packets into the resulting "parsed" packets or sub

1 packets or the deletion of junk packets or sub-packets from the resulting "parsed" packets 2 or sub-packets. 3 The inverse function, packet-mixing operation 1060 shown in FIG. 7B, combines 4 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 6 mixing method. The algorithm may represent a static equation or include dynamic 7 variables or numerical seeds or "states" such as time 920 used to specify the conditions 8 when incoming data packets 1055 and 1056 are mixed. The mixing operation used to 9 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 11 used to identify a specific mixing algorithm chosen from a list of available mixing 12 methods, i.e. from mixing algorithms 1050. In data flow diagrams, it is convenient to 13 illustrate this packet mixing operation using a schematic or symbolic representation, as 14 depicted herein by the symbol shown for mixing operation 1061. In accordance with this invention, packet mixing and splitting may utilize any of a 16 large number of possible algorithms. FIG. 8 illustrates three of many possible mixing 17 techniques comprising concatenation, interleaving, or algorithmic methods. In 18 concatenation, the data segment sequence of data packet 1056 is appended onto the end 19 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, 21 etc. to form mixed data packet 1065. Other methods used for packet mixing involve an 22 algorithm. In the example shown, an algorithm comprising interleaved reflective 23 symmetry alternates the data segments in the order of 1A, 2A, 1B, 2B, IC, 2C in the first 24 half of the mixed packet 1066, and in the opposite order for the second half, i.e. 2D, ID, 2E, 1E, 2F, IF. 26 The application of data packet mixing and splitting in a SDNP network is 27 described in the above-referenced U.S. Application No. 14/803,869, entitled "Secure 28 Dynamic Communication Network and Protocol". FIG. 9A summarizes SDNP 29 functional elements including functions and their corresponding inverse operation, i.e. anti-functions, as well as dynamic components of the corresponding functions, i.e. the 31 state or time of each function when executed on a data packet. SDNP function including

1 scrambling operations comprising packet scrambling 926 and its anti-function packet 2 unscrambling 928; fragmentation operations comprising splitting 1057 and its anti 3 function mixing 1061, deception operations comprising junk insertion 1053A and junk 4 deletion 1053B, along with encryption operations comprising encryption 1026 and decryption 1032. All these functions occur uniquely in accordance with time or state 6 variables 920. 7 The application of data packet mixing and splitting, along with scrambling, 8 unscrambling, encryption, decryption, and deception in Last Mile communication 9 collectively comprise the SDNP Last Mile security operation. This SDNP Last Mile security operation is "directional" meaning the operation performed for and on all 11 outgoing data packets is different than the operations performed on incoming data 12 packets. 13 The SDNP Last Mile security operation is also symmetric and reversible over the 14 Last Mile, meaning that using local security credentials such as keys, seeds, shared secrets specific to the particular Last Mile, the operations performed on an outbound data 16 packet in a client's device are undone in the SDNP gateway, generally by performing the 17 anti-function, i.e. the mathematical inverse, or every functional operation originally 18 executed by the client's device but in reverse sequence. As such, the SDNP gateway is 19 enabled to recover the original content in preparation for routing through the SDNP cloud. Similarly, for incoming data packets into a client's device using zone-specific 21 security credentials for the Last Mile, the SDNP Last Mile security operation executed in 22 the client device undoes each security operation performed by the SDNP gateway by 23 executing the anti-function in reverse sequence. In this manner, the client device can 24 recover the original data on all incoming data packets. The SDNP Last Mile security operation is dynamic and localized, i.e. zone 26 specific, using state dependent conditions, e.g. location, time, etc. to determine which 27 parameters were used at the time the data packet was prepared and for what region, 28 geography, or locale specific for a particular Last Mile. By being localized, data packet 29 preparation performed in different regions and over different Last Mile connections never have the same coding or use identical security credentials. Furthermore, these Last Mile 31 security credentials always differ from those used in the SDNP cloud. Moreover, being

1 dynamic, the state used for creating the data packets changes constantly, further 2 obfuscating the actual security process performed on each data packet and rendering no 3 two data packets alike. 4 By the unique combinational application of directional symmetric reversible dynamic localized security operations specific to each Last Mile communication, the 6 algorithmic application of dynamic scrambling, dynamic fragmentation, dynamic 7 deception, and dynamic encryption made in accordance with this invention insures 8 HyperSecure communication not achievable from the use of simple static encryption 9 methods. The pervasive application of dynamic methods valid for durations of only tens of milliseconds not only makes interpretation nearly impossible, but gives a hacker no 11 time in which to decipher or interpret the data packet before another arrives. In practice, 12 SDNP Last Mile security operations may be executed using software, firmware, 13 hardware, dedicated security ICs, or any combination thereof 14 Although a myriad of combinational sequences are possible, one example of SDNP Last Mile security operation is illustrated in FIG. 9B specifically for serial SDNP 16 payloads used in single-route Last Mile communication, i.e. where a client's device 17 communicates to a single SDNP gateway. The process involves two directional 18 operational sequences, one for outgoing data packets, the other for incoming data 19 packets. In the case of outgoing data packets, shown in the upper half of the illustration, "data to be sent" is first scrambled using packet-scrambling operation 926, then deception 21 is performed by the insertion of junk data 1053A. In some cases an entire packet may 22 comprise entirely junk data, further confusing data mining attempts by hackers. 23 These packets are then split into multiple pieces by splitting operation 1057 using 24 parsing operation 1052 and sent separately to encryption operation 1026. Each piece is then encrypted using common or distinct encryption keys and the resulting ciphertext is 26 arranged into a serial SDNP payload shown as data packet 1199A. The packet is then 27 formatted into IP data packets, i.e. "IP packet preparation", in preparation for 28 communication onto the Last Link and Last Mile. All operations performed are dynamic, 29 occurring at a particular time or with a specific state 920A during the security process execution.

1 In the case of incoming data packets shown in the lower half of the illustration, 2 incoming data from the Last Link comprising a serial SDNP payload 1199B, i.e. from "IP 3 packet recognition" is first decrypted in pieces or as a whole by decryption operation 4 1032 followed by mixing operation 1061 to recover the true data stream. The data packets are then de-junked, i.e. the junk data is removed from the data packets using de 6 junk operation 1053B, followed by packet unscrambling operation 928 to recover the 7 "data received". All operations performed on incoming data packets must use the state 8 920B used when the SDNP gateway created the data packet, i.e. containing information 9 of a particular time or with a specific state 920B at the packet's birth. This state information may be sent through a different communication by a signaling server or may 11 be carried in the incoming data packet as plaintext or alternatively as static ciphertext, i.e. 12 with a decryption key already known by the SDNP Last Mile security operation. Details 13 of state 920B, cannot however, be encrypted using a key requiring the state information 14 contained within state 920B, or otherwise the code will be unable to open and use its own security credentials. 16 Another example of SDNP Last Mile security operation is illustrated in FIG. 9C 17 specifically for parallel SDNP payloads used in multi-route Last Mile communication, 18 i.e. where a client's device communicates to multiple SDNP gateways. Like its single 19 route counterpart described previously, the process involves two directional operational sequences, one for outgoing data packets, the other for incoming data packets. In the case 21 of outgoing data packets, shown in the upper half of the illustration, "data to be sent" is 22 first scrambled using packet-scrambling operation 926, then deception is performed by 23 the insertion of junk data 1053C. In some cases an entire packet may comprise entirely 24 junk data, further confusing data mining attempts by hackers. These packets are then split into multiple sub-packets by splitting operation 1057, 26 using parsing operation 1052, and sent separately to encryption operation 1026. Each 27 piece is then encrypted using common or distinct encryption keys and the resulting 28 ciphertext is arranged into multiple SDNP payloads shown as data packets 1199C, 29 1199D, and 1199E. The packets are then formatted into separate and distinct IP data packets, i.e. "IP packet preparation", in preparation for communication onto the Last Link

1 and Last Mile. All operations performed are dynamic, occurring at a particular time or 2 with a specific state 920C during the security process execution. 3 In the case of incoming data packets shown in the lower half of the illustration, 4 incoming data from the Last Link comprising parallel SDNP payloads 1199F, 1199G, and 1199H, i.e. from "IP packet recognition" are first decrypted piecewise by decryption 6 operation 1032 followed by mixing operation 1061 to recover the true data stream. The 7 data packets are then de-junked, i.e. the junk data is removed from the data packets using 8 de-junk operation 1053D, followed by packet unscrambling operation 928 to recover the 9 "data received". All operations performed on incoming data packets must use the state 920D used when the SDNP gateway created the data packet, i.e. containing information 11 of a particular time or with a specific state 920D at the packet's birth. This state 12 information may be sent through a different communication by a signaling server or may 13 be carried in the incoming data packet as plaintext or alternatively as static ciphertext, i.e. 14 with a decryption key already known by the SDNP Last Mile security operation. The SDNP Last Mile Security operation need not use the same algorithms or 16 methods for both incoming data and outgoing data packets. As exemplified in FIG. 9D, 17 outgoing data packets use SDNP Last Mile Security operation 1190A while incoming 18 data packets use SDNP Last Mile Security operation 1190B. Referring to the upper half 19 of the illustration, outgoing data packets may carry data representing any combination of real time data sources from transducers or sensors, or may contain files made prior to 21 communication. For example, sound 1198A converted into electrical signals by 22 microphone 1180 and video signals from camera 1181 are converted into an equivalent 23 digital format by audio video CODEC 1182A. The formats created generally involve 24 standards such png, pic, mpeg, mov, etc. interpretable and interoperable with standard devices in accordance with OSI Layer 6, the presentation layer. Using standard audio 26 video formats avoids the need to transmit proprietary code for opening a file between 27 source and destination addresses. 28 The digital output of audio video CODEC 1182A is then mixed with textual data 29 from virtual keyboard 1183 (a keypad realized on a touch screen) and with data files 1179A using content mixer 1184. This mixer, in turn, sends data files to SDNP Last Mile 31 security operation 1190A, and provides SDNP header information to IP packet

1 preparation operation 1191A in order to identify and label real time data packets from 2 static files. SDNP Last Mile security operation 1190A then passes the secure data packets 3 to IP packet preparation operation 1191A, which thereafter embeds the SDNP payloads 4 into IP data packets in accordance with routing instructions received by the SDNP signaling server 1603. The data packets my be distributed into multiple IP packets for 6 multi-route Last Mile communication or may be concatenated into a serial data string and 7 embedded and fit into one or more serial data packets for singe route Last Mile 8 communication. These packets are then passed in to the client PHY operation 1192A to 9 add Layer 1 and Layer 2 data to complete the IP data packet. In the reverse operation shown in the lower half of the illustration, incoming data 11 from the Last Link received by client PHY 1192B is passed to IP packet recognition 12 operation 1191B, which identifies the incoming data as a valid message or as an 13 unknown and possibly malicious data packet. Valid messages are identified using SDNP 14 tags, seeds, keys, and other identifiers communicated beforehand to the client device and to IP packet recognition operation 1191B by signaling server 1603. 16 Anthropomorphically, IP packet recognition operation 1191B expects and even 17 anticipates valid incoming data packets. Unexpected data packets lacking proper 18 identification are discarded and never opened or processed further. In this manner, a 19 hacker cannot disguise themselves and send valid data to any SDNP node without first registering their identity to the SDNP cloud. 21 IP packet recognition operation 1191B passes the valid data packets to SDNP Last 22 Mile security operation 1190B, which in turn performs all necessary operations to 23 reconstruct the true content of the data packet - data comprising a serially arranged 24 amalgamate of video, audio, text, and data files. Content de-mux 1193, a de-multiplexer that undoes the mixing operation used in data packet creation, e.g. it un-mixes the serial 26 data file created by mixer operation 1184 performed in the other caller's phone, is then 27 used to separate the various file types. Outputs of content de-mux 1193 include text 28 shown displayed in messenger window 1196, data files 1179A, and real time data sent to 29 audio video CODEC 1182B. Audio video CODEC 1182B converts the digital presentation layer data into live video images 1195 or via speaker 1194 into sound 31 1198B.

1 For Last Mile data transport, data must be embedded or wrapped in a multi-tiered 2 arrangement shown in FIG. 9E similar to the aforementioned Babushka Russian nesting 3 doll model. Accordingly, SDNP payload 438 represents the transport payload 437, which 4 together with transport header 436 comprises IP payload 435. The combination of IP payload 435 with IP header 434 represents an IP datagram, equivalent to MAC payload 6 432. Wrapping MAC payload 432 within MAC header 431 and MAC footer 433 results 7 in the MAC "frame", the frame being equivalent to physical layer 490, also known as the 8 PHY Layer 1 content, comprising a physical media such as electrical signals, light, radio 9 waves, or microwaves. In SDNP routing, MAC header 431 in Layer 2 describes the MAC connection for 11 the Last Link, i.e. the connection between the client device and the first device in the Last 12 Mile link. By using source and destination addresses of the client device and the SDNP 13 gateway, header 434 in Layer 3 specifies the end points of routing over the Last Mile. 14 Because the Last Mile is not part of the SDNP cloud however, the precise route data packets take over the Last Mile is not explicitly stated or controllable. In SDNP Last Mile 16 communication, transport header 436 in Layer 4 specifies UDP is used for SDNP real 17 time payloads, and also specifies the ad hoc assigned SDNP port address used in each 18 packet - an address changing dynamically to thwart port interrogation cyber-attack 19 strategies. SDNP payload 438, the payload of the Last Mile IP packet, contains SDNP 21 preamble 1198 containing zone information, keys, and seeds, and SDNP data field 22 1199A, a serial string of multiple segments of independently encrypted ciphertext. The 23 decrypted form of the ciphertext comprises plaintext files 1197A, 1997B, and 1197C, 24 each containing their own unique SDNP header, and corresponding data files data 91, data 92, and data 93 respectively. The individual sub-headers include information 26 involving tag, zips, addresses, urgency, and QoS data as applicable. 27 The roles of SDNP preamble and headers vary depending on the command and 28 control methods employed. In tri-party Last Mile communication, a signaling server 29 instructs the client device and the SDNP gateway or gateways how to communicate with one another to make a call, send a file, or open a session. As such, the instructions are 31 communicated to both devices using a command and control data packet with TCP

1 transport prior to sending any media data packets. As such, the minimum data required in 2 the Last Mile communication between the client and the SDNP gateway is a tag or 3 address used to identify the incoming packet. In some cases, for example, if a signaling 4 server cannot be reached, then in an alternative embodiment, the SDNP data packet can carry additional data in its preamble and packet headers. 6 The data packet and accompanying table 1177 shown in FIG. 9F illustrates one 7 exemplary format used to carry SDNP information within SDNP payload 438. The data 8 packet comprises SDNP preamble 1198 and one to eight data field headers 1178X with 9 their corresponding data fields "Data X Field". Each data field such as "data 1 field", "data 2 field" etc. is preceded by its own corresponding header Hdr 1, Hdr 2, etc. and 11 carries the content of a communique including voice, text, video, pictures, movies, files, 12 etc. The number of data fields can vary from one to eight as determined by the 4b long 13 field #, i.e. from binary 0001 to binary 1111. The length of SDNP preamble 1198 and 14 SDNP payload 438 is affected by the Field # specification. If only one field is selected, i.e. where Field #= 0001 binary, SDNP preamble 1198 will contain only LFld 1 (L Fld 2 16 thru LFld 8 will be eliminated) and SDNP payload 438 will include only Hdr 1 and the 17 data 1 field. If the maximum of eight fields is selected, i.e. where Field #= 1111 binary, 18 then SDNP preamble 1198 will contain eight length specifications L Field 1 to L Field 8 19 and SDNP payload 438 will include eight data fields and headers in sequence as Hdr 1, data 1 field, Hdr 2, data 2 field, . . Hdr 8, data 8 field. As shown, SDNP preamble 1198 21 contains the field length specifications L Fld 1, LFld 2 and L Fld 8. The small gap 22 between LFld 2 and L Fld 8 is meant to represent the sequence continue and does not 23 represent a gap in the data. 24 The length of each data field specified by L Fld X can vary from zero or OB (a null data field), to a maximum hexadecimal length of FFFF or 65,535B. For practical 26 reasons of compatibility with Ethernet, the maximum data packet length for any one field 27 is preferably limited to 1500B or hexadecimal 05DC, and the aggregate length of all data 28 fields should not exceed the jumbo packet size of 9000B or hexadecimal 2328. The 29 specified length of each data field can vary independently. A zero field length, e.g. where L Fld 8 = 0000 hexadecimal, results in elimination of the corresponding data 8 field but

1 does not eliminate the corresponding header Hdr 8. Headers are only eliminated by Field 2 #specification. 3 In accordance with this SDNP protocol, the apportionment of content across the 4 various data fields is extremely flexible. Data directed to single destination may be contained within a single data field, or for purposes of deception may be split into 6 multiple data fields and merged with junk data. The size of the data fields may vary 7 independently. Data fields may also be included containing purely junk data or 8 alternatively entire data packets may be generated containing only junk data. For efficient 9 packet routing however, data targeted for different destinations should be partitioned into separate data fields each with their own unique headers. 11 The SDNP packet format is applicable for end-to-end transport throughout the 12 entire SDNP network including across multiple clouds and zones such as the SDNP cloud 13 or in Last Mile communication. Although the contents of the SDNP data packets change 14 as they traverses the network, the SDNP packet format remains unchanged. Since this format includes minimal data overhead, the SDNP data packet format is equally 16 applicable for large payloads or for time critical real-time communication. The packet 17 format is applicable for bidirectional data flow, i.e. for data flow from the Last Mile into 18 an SDNP gateway and across the SDNP cloud, or conversely for delivery of data packets 19 emanating from the cloud, exiting a SDNP gateway for transport across the last mile to the destination client device. 21 In operation, the direction of SDNP data routing is determined by the Network 22 Layer-3 source and destination addresses described within IP header 434 of FIG. 9E. 23 Each packet is loaded with its source and destination addresses at the time the media 24 node prepares the packet for transmission to the next media node on its route. In tri channel communication the SDNP or IP address of a packet's destination is delivered 26 from a signaling server to the media nodes as a command and control (C&C) packet prior 27 to outgoing packet preparation. In general, the signaling server is able to send C&C 28 instructions to every node in a communication path including both sending (caller) and 29 destination (callee) devices. In the event that only single channel communication is available, e.g. in a link with long propagation delays, then the signaling server is unable 31 to pre-warn a media node of an incoming packet or what to do with it. In such an event,

1 the routing addresses are carried within the incoming data packet in SDNP payload 438. 2 In such cases, the media server follows default instructions on how to process the 3 incoming packet using data fields contained within the incoming SDNP packet including 4 routing and state information as well as security credentials. Payload 438 is made of two portions, a readable portion comprising preamble 6 1198, and an unreadable potion 1199a containing data in a "concealed form". The content 7 of this packet may employ any number of concealment techniques to obscure its content 8 such as encryption, scrambling, and possibly containing junk data. The concealment 9 method must be undone to extract usable content 1197a, 1997b and 1197c. These packets contain the destination addresses of the future outgoing packets. The addresses exist only 11 in an unconcealed or decrypted form for only a brief moment before the next packets can 12 be prepared and encrypted. 13 As described, SDNP preamble 1198 comprises information relevant to the entire 14 packet. Aside from the data field specifications, FIG. 9F illustrates SDNP preamble 1198 also includes the SDNP zone where the SDNP packet was created, e.g. zone Ul, two 16 numeric seeds, and two keys. These keys and seeds may be used as zone specific security 17 credentials in the scrambling/unscrambling, junk insertion/deletion, mixing/splitting, and 18 encryption/ decryption process. The seeds and keys can be used as the exclusive means 19 for the delivery of security credentials needed in opening and reading the data fields, or may be used in conjunction with command and control packets sent to the client's device 21 and to the SDNP gateway from the signaling server, a network of command and control 22 computers not involved in carrying communique content in media packets. 23 Seeds and keys can be delivered securely in public, i.e. in non-encrypted form, 24 because the data lacks the information needed to use them - they comprise only part of the security credential. The other portions of security credentials, the missing pieces, may 26 be sent previously in another data packet, or may comprise shared secrets of algorithms, 27 look-up tables, and codes not delivered over the network and not part of the message. 28 Encryption keys may be symmetric keys, where both the sender and the recipient hold the 29 key, or public keys, where the public, including the sender, has access to the encryption key but only the recipient, i.e., the party generating the encryption key, holds the 31 decryption key. Moreover, all the security credentials are limited to a specific security

1 zone, e.g. Ul, and are dynamic, limited to a specific time or state that expires if unused 2 within a specified time. If the seed and key data fields are not used as security credentials, 3 e.g. because the signaling server independently instructs the SDNP devices regarding 4 security operations, then these fields can be filled with numeric values falsely appearing as encryption keys, misdirecting a cyber-attacker into wasting time analyzing a decoy 6 security key. 7 In Last Mile communication, the intermediate routers between the client's device 8 and the SDNP gateway do not process, interpret or open the transported data packets 9 because they are not part of the SDNP network and lack the ability to query or interpret the SDNP packet data contained within. Instead, all security operations are exclusively 11 executed at the two end points, the SDNP client and the SDNP gateway because only 12 these devices operate as SDNP communication nodes. Since each end point executes 13 SDNP protocols dynamically, the Last Mile communication is HyperSecure over the 14 entire Last Mile. If the other calling party also runs SDNP software, then the second party's Last Mile is also secured by the aforementioned SDNP methods and HyperSecure 16 communication is guaranteed "end to end" - from one caller to the other. 17 In the event, however, that the end device is not a SDNP client, then the router 18 nearest the caller, i.e. the Last Link router, can be enabled with SDNP firmware, and the 19 Last Link can be reasonably secured from special functions performed by the SDNP enabled router even though it is not SDNP enabled. This alternative Last Link security 21 method is described in greater detail in subsequent sections of this disclosure and will not 22 be elaborated upon in this section. The described method, while applicable for securing 23 Last Link communication, is not sufficient for protecting other portions of the Last Mile. 24 Referring again to FIG. 9F, each and every SDNP data field is accompanied by a SDNP data field header 1178X containing information uniquely applicable to its 26 associated data field but not useful for other data fields. Specifically, in the disclosed 27 embodiment, each header contains a data type field describing what kind of data is 28 contained within the associated data field, a destination address field used for identifying 29 the specific data field and its destination, a field zone used to carry forward zone information from one zone to another, as well as urgency and delivery information. As 31 shown each SDNP data payload 438 contains one SDNP preamble 1198, and one or more

1 SDNP data field headers 1178x and corresponding data x fields, where x describes the 2 number of separate payloads which may range from 5 to 50 depending on the size and 3 urgency of the payloads. 4 Although the signaling server may supply most of the described information to the SDNP client and SDNP gateway, one fundamental component necessarily carried by 6 the Last Mile data packet is an "address field" or tag needed to identify the data packet. 7 The field, referred to as the SDNP payload's destination address (abbreviated in the 8 illustration as "Dest Addr"), may comprise any unique identifier sufficient to distinguish 9 the identity of one data field from another. Its purpose is similar to the function of bar codes used to tag and track luggage in an airport or boxes shipped by a courier. Address 11 types may for example comprise a numeric tag, a SDNP zip, an IPv4 or IPv6 address, a 12 NAT address, or even a POTS regular phone number, so long that the identifier is unique 13 to prevent conflict in identifying the data packet. The size of the destination address field 14 varies with the type of address type selected. To maintain packet anonymity during routing, it is preferable to employ 16 confidential codes such as a SDNP Zip code as the SDNP destination address rather than 17 using true phone numbers or IP addresses. In operation, whenever a data packet from an 18 SDNP client arrives at a SDNP gateway, the SDNP payload is decrypted and then each 19 data field header is inspected for the identifying destination addresses. Before the data header can be inspected, the data packet must be decrypted or processed to undo the 21 concealment methods used in the packet's creation. In the case of dual-channel or tri 22 channel communication, as shown in FIG. 9G, the signaling server 1603 has previously 23 informed the SDNP gateway about the planned arrival of the data packet and its 24 corresponding identification marking and security credentials. As such, when the SDNP gateway receives data packet 438A comprising Last Mile communication sent from a 26 SDNP client, the gateway performs SDNP last mile security operation 1190D in order to 27 convert the SDNP payload from ciphertext into plain text data packet 438B. A security 28 operation describes the processing of modifying an outgoing data packet to conceal its 29 content and the process to modify an incoming data packet to reveal its content. Specifically, the security operation performed on an incoming data packet is used to 31 recover its content by undoing concealment operations performed on it before its

1 transport, including using decryption to undo encryption, unscrambling to undo 2 scrambling, dejunking to remove junk insertions, and mixing to undo splitting. These 3 processes are performed in accordance with the state and zone of the data packet when it 4 was created. For outgoing data packets, a security operation involves concealing the contents of a data packet prior to transport by performing encryption, scrambling, junk 6 insertions, and packet splitting in accordance with the state and zone when the data 7 packet is created. The unencrypted seed and key data fields in the data packet 438A can 8 be neglected or optionally used in conjunction with signaling server information to 9 decrypt the ciphertext. The resulting operation reveals data field 1 and its associated data field header 117D labeled as Hdr 1 containing the data field's destination address, data 11 type, urgency and delivery information. In such cases, the destination address is not a 12 routing address but only a SDNP Zip, i.e. a tag used to identify the packet is part of a 13 particular conversation. 14 Once a specific data field is found to contain the identified destination address, e.g. a SDNP Zip code, matching instructions from signaling server 1603, the data field is 16 extracted, optionally mixed with other related content by mixer 1184Z and rewrapped 17 into a new IP or SDNP datagram by SDNP packet preparation operation 1191Z for 18 delivery to its next destination. The new data packet headed into the cloud includes an 19 SDNP header 434Z containing the destination of the new packet and the data content, SDNP payload 435Z. The destination supplied by the signaling server 1603 to the 21 gateway media node as an IP address or SDNP address may comprise another SDNP 22 server operating as a SDNP cloud node or may involve Last Mile communication to 23 another SDNP client. In such tri-channel communication cases, the destination address is 24 not really an address but a means to identify the packet, where its next destination is already known by the SDNP gateway. In the case where the destination of the packet is 26 for SDNP cloud routing the data packet is then processed by SDNP cloud security 27 operation 1190Z in accordance with Z Isecurity credentials for the cloud, not U1 28 credentials used in the Last Mile. 29 In single channel communication, as shown in FIG. 911, a signaling server is unable to advise the SDNP gateway in advance of the imminent arrival of a data packet 31 and its data fields, either because (i) there is no signaling server operating in the local

1 network, (ii) the signaling servers are temporarily offline, or (iii) the signaling server is 2 too busy and unable to preemptively route the packets in time. In such cases, the data 3 packet 438A from the SDNP client must carry the necessary security credentials Zone 4 Ul, Seed 1, Seed 2, Key 1 and Key 2 to decrypt the data packet using SDNP Last Mile security operation 1190D converting ciphertext data packet 438A into plaintext data 6 packet 438B. The standard SDNP data packet format reserves these data fields even if the 7 contents of the field is not required by a particular media node. For example if a specific 8 concealment process used to create a data packet does not use the Key 2 field, the data in 9 that field is meaningless and is not used by the destination node. Nonetheless, the data packet reserves the same number of bytes for the field used or not, so that all SDNP data 11 packets are homogeneous in format. Once it has decrypted the ciphertext in data packet 12 438A, the SDNP gateway extracts the content of the data packet data 1 field and its 13 associated Hdr 1 field header 1178D from plaintext data packet 438B. From this data 14 packet, IP packet recognition process 1191D combines the data fields for A Type and Destination Address from Hdr 1 field header 1178D for two reasons - firstly in tri 16 channel communications to confirm the incoming packet is expected, and secondly to 17 produce a new SDNP address. This new SDNP address is combined with D Type, 18 Urgency and Delivery fields and processed by SDNP packet preparation operation 1191Z 19 to create SDNP header 434Z in the outgoing data packet. The content of Data 1 Field is also extracted from incoming plaintext data packet 438B, and its content is optionally 21 mixed 1184Z with other outgoing content to create outgoing SDNP payload 435Z. The 22 packet is then processed by SDNP cloud security 1190Z in preparation for forwarding. In 23 this way, the address field performs multiple functions, both to identify an incoming data 24 packet and to provide a forwarding address when needed. If a media node receives a data packet without first receiving instructions from a 26 signaling server, the media node will revert to default instructions as to how to process 27 the incoming data packet, and how to prepare outgoing data packets. Should the media 28 node not hold any instructions on how to handle unannounced incoming packets, the data 29 packet will be discarded. If the media node is enabled with instructions on how to process unidentified packets, the media node will first confirm in accordance with security 31 credentials that the packet is a valid SDNP packet, and process it accordingly. If the

1 sender cannot, however, be identified, e.g. if an encryption code, seed, or source address 2 is invalid, then the packet will be discarded as a fraud. 3 Returning to FIG. 9F, the packet field labeled "Field Zone" describes the zone 4 where a specific field was created, i.e. whether a past encryption or scrambling was performed with, for example, Ul or U2 zone settings. In cases of nested security 6 protocols or other nested concealment methods, unscrambling, decrypting, or undoing 7 concealment of a data packet requires additional information, e.g. a key, seed, time or 8 state, in which case the packet field labeled "Field Other" may be used to carry the field 9 specific information. In general these fields are not employed except in nested security protocols, e.g. where an encrypted data field is then scrambled or encrypted a second 11 time. Care must be taken when employing nested security methods to perform the 12 recovery of data in precisely the reverse order of the data packet's preparation, or the 13 content will be lost forever. 14 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 16 communication from data packets containing time sensitive information such as voice 17 and live video, i.e. to distinguish real-time routing from non-real-time data. Data types 18 include voice, text, real-time video, data, software, etc. 19 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, 21 normal, priority, and urgent categories. Delivery includes various QoS markers for 22 normal, redundant, special, and VIP categories. In one embodiment of this invention, the 23 binary size of the various data fields as shown in table 1177 is chosen to minimize the 24 required communication bandwidth. For example, data fields as shown may range from 0 to 200B whereby eight data fields of 200B per data field means that a SDNP packet can 26 carry 1,600B of data. 27 Both FIG. 9G and FIG. 9H illustrate the case where a client device sends data 28 packets in zone Ul over the Last Mile to a gateway node. The gateway node then 29 processes the incoming data packets to undo the Last Mile security and concealment methods employed using zone Ul security credentials. The gateway nod may then mix 31 the content of the packet with the content of other packets in mixing process 1184Z to

1 create a new packet (or packets) bound for transport through the SDNP cloud using the 2 security credentials of Zone Z1. 3 A similar process is employed when the SDNP gateway receives a data packet 4 from the cloud (including another gateway) and sends the data packet to a client device, e.g. from the SDNP cloud to the client's phone (the callee). As shown in FIG. 91, in dual 6 channel or tri-channel communication signaling server 2603 has previously informed the 7 SDNP gateway about the planned arrival of the data packet and its corresponding 8 identification marking and security credentials coming from the cloud. As such, when the 9 SDNP gateway receives data packet 2438A from the SDNP cloud, the gateway performs SDNP cloud security operation 2190D in order to convert the SDNP payload from 11 ciphertext into plain text data packet 2438B. The unencrypted seed and key data fields in 12 the data packet 2438A can be neglected or optionally used in conjunction with signaling 13 server information to decrypt the ciphertext. The use of the data fields depends on the 14 algorithms employed in concealing the packet's payload. For example, if encryption is not used then the fields containing encryption keys are neglected. 16 The resulting operation extracts a number of data fields. A subsequent operation 17 splits these data fields in content-splitting operation 2184Z to extract specific content 18 comprising data field 1 and its associated data field header 2117D labeled as Hdr 1 using 19 recognition operation 2191D. Header Hdr 1 contains the data field's destination address, data type, urgency, and delivery information. The extracted data field is then rewrapped 21 into a new IP or SDNP datagram by SDNP packet preparation operation 1191Z for 22 delivery to its next destination. The new data packet headed into the cloud includes an 23 SDNP header 2434Z containing the destination of the new packet (the IP address 24 corresponding to the person's phone number) and the data content, SDNP payload 2435Z. The outgoing packet then processed by SDNP Last Mile security operation 2190Z 26 in accordance with U1 security credentials for the Last Mile, not Z1 credentials used in 27 the cloud. 28 If a signaling server is not available, i.e. in single-channel communication, then 29 the media node must process an incoming data packet using instructions previously delivered it as a default instruction. In such instances, the incoming data packet is 31 checked against criteria needed to confirm the sender is a valid SDNP client (such as a

1 SDNP zip code or an authentication code delivered previously as a predetermined shared 2 secret). If the packet is determined to be valid, the packet is processed in accordance with 3 the default instructions. If not, the packet is discarded. 4 The aforementioned methods are exemplary and not intended to limit the processing and routing of data packets to a particular data packet format. 6 Security and Privacy in Communication 7 An important consideration in Last Mile communication is a network's ability to 8 support both secure communication and private communication. Although privacy and 9 security are often associated, they are not the same thing. Security as the term is used in communication is considered the "discipline to prevent unauthorized access to 11 communication data in recognizable form". Security does not however, cover cases 12 where an individual or agency has the right to access or monitor a communication. 13 Privacy is defined as "the state or condition of being free from being observed or 14 disturbed by other people and in being free of public attention". In legal terms privacy is defined to be a person's right to control access to his or her personal information. 16 In communication, the privacy rights of an individual in their voice calls, video, 17 text, emails, personal messaging, etc. vary dramatically by country. The role in 18 complying with applicable governmental regulations to provide legally valid access to 19 communication is discussed in a subsequent section. That aside, an ideal network and communication system should be able to prevent hacking of communication, i.e. it should 21 be absolutely secure, and it should be capable of insuring all communications are limited 22 to those with the right to know, i.e. it should be private. 23 When assessing the privacy and security capabilities of a network, the network's 24 Last Mile and its connected devices must be considered carefully. Depending on the security credentials used to establish information access privileges, the Last Mile and its 26 connected devices frequently determine a network's security and privacy, i.e. the Last 27 Mile represents the weakest link. Four possible combinations of communication networks 28 must be considered: 29 • Secure and private networks. From an individual's perspective, this case represents ideal network performance, one that insures both security of the 31 information and privacy for the individual. In its extreme, a truly secure private

1 network means any individual, government, agency or corporation can not 2 intercept meaningful communication nor obtain private data about a person's 3 behavior, actions, their contacts and associates, their personal preferences and 4 activities, etc. Although privacy rights advocates consider an idealized secure private network as the gold standard in confidential communication, governments, 6 security organizations, and corporations view absolute autonomy in 7 communication as problematic, allowing individuals to engage in criminal 8 activities and terrorism with absolute secrecy and impunity. 9 • Unsecure networks lacking privacy. A network that is not secure and has no privacy provisions (such as Internet OTT carriers today) represents a 11 severe risk to any individual, group, club, company, or government using the 12 communication channel. Because a cyber-hacker can easily access calls and data, 13 any malevolent party can use this information for any purpose they choose. For 14 practical jokers and spammers, unsecure communication channels can be commandeered to invoke chaos, flood networks with spam, initiate denial of 16 service attacks, and create damaging mischief. For ideologues, political activists, 17 and religious cults, unsecure communication can be used to leak sensitive 18 information to precipitate political change, discredit government officials, 19 stimulate riots, or even topple governments (see the historical fiction movie "The Fifth Estate" (DreamWorks ©2013) as an example chronicling WikiLeaks 21 release of hundreds of thousand of sensitive government documents precipitating 22 a firestorm of international repercussions). For economically motivated cyber 23 criminals such as those associated with organized crime and mafia, attacks focus 24 on money crimes, for example, theft, diversion of funds, fraud, identity theft, money laundering, extortion, blackmail, and other felonies. For those involved in 26 fear and intimidation such as drug cartels, gangs, and terrorists, unsecure 27 communication can be monitored to track the location, movements, and actions of 28 their competitors, enemies, and targeted victims for purposes of planning and 29 implementing violent crimes such as assaults, kidnapping, murder, bombings, or acts of terrorism. Finally in the case of personal cyber-attacks, unsecure 31 communications can be used to illegally hack databases containing individuals'

1 private information including social security numbers, passports, banking 2 information, credit card information, medical records, and other personal 3 confidential information. 4 • Secure networks lacking privacy. Examples of secure networks lacking privacy commonly include corporate accounts where the IT (information 6 technology) manager or security department have the right and authority to 7 monitor all corporate communications to insure no inappropriate or illegal 8 communication is occurring over the company's network. Even though the 9 network is secure from hackers and cyber-criminals, the communications on such a network are not private and may be monitored by authorized agents to detect 11 wrongdoing including unauthorized personal use of company communication 12 infrastructure, corporate espionage, violation of confidentiality agreements, 13 unauthorized disclosure of intellectual priority (P leaks), sexual harassment, 14 violations of the fair disclosure regulation (reg. FD), insider trading, violation of FCPA (foreign corrupt practices act), graft, bribery, fraud, financial reporting 16 violations, securities violations, and more. In corporate communication, an 17 individual is informed upon joining the company that their corporate 18 communications are not private and may be monitored including company phone 19 calls, email, text, personal messaging and SMS, and other communique. In the case of court proceedings, whether civil or criminal, these communiques may also 21 be subpoenaed and entered into evidence in court even if personal information is 22 comingled with corporate information. In essence if an employee of a company 23 utilizes company communication, devices, and networks for personal use, then 24 (except in the case of attorney-client privilege) all the information is fair game and should not be considered private. For this reason and others, the mixed use of 26 personal messengers such as Line and KakaoTalk for business and personal use is 27 especially problematic because an employee cannot invoke privacy rights to 28 prevent inspection of their text chats, pictures, and files. 29 • Quasi-private, unsecure networks. A quasi-private unsecure network is one where the network carrying the data can be hacked, e.g. wire 31 tapped, but private transactions can be confidentially performed despite the lack

1 of security provided certain conditions are met. In this manner privacy is 2 established by confirming the identity of a caller (or callers) by various means 3 using shared secrets, undiscoverable even by a hacker intercepting the call. A 4 common example of a private unsecure communication is a voice banking transaction. The caller confirms their identity by answering a series of ever 6 changing questions to which an imposter would be unlikely to know the answers, 7 e.g. "we see you ate dinner last night and paid with our credit card. Could you tell 8 me what city did you eat dinner in?" Or, "you receive a regular billing from a 9 winery. What winery is it?" Another example question is "could you tell me the last name of your favorite grade school teacher?" For these methods of identity 11 verification to work, the bank must either have access to non-public information 12 (such as credit card statements) or the bank and its clients must establish a set of 13 shared secrets when the account was first set up, generally in person and not 14 electronically. After the identity if the caller is confirmed, the client can instruct the institution to perform certain actions that would not benefit a cybercriminal. 16 For example, "please move $10,000 from my savings to my checking account." If 17 the money transfer is wired to another bank, however, even a more rigorous 18 verification must occur to insure the client's privacy. In any case, privacy depends 19 on meeting the condition that the communication cannot reveal shared secrets either electronically or aurally, otherwise all privacy is lost and accounts may be 21 at risk. As such authenticated communication on an unsecure line is referred to as 22 quasi-private meaning conditional privacy. Another example or quasi-private 23 communication over a unsecure network can be performed by utilizing a security 24 token, a device issued by the bank that only the client possesses. The pseudo random number generated by the device is told to the bank's operator who 26 confirms the number is consistent with the bank's authorized numbers. Since the 27 number is 8 or more digits the chance of guessing the right code the first time is 28 miniscule. If the wrong token number is reported, the call is terminated, the 29 account is frozen, and the fraud department is alerted to investigate. In any such case, the importance of insuring privacy over an unsecure network depends on 31 being able to communicate without verbally revealing any confidential details

1 such account numbers, PINs, credit card information, etc., i.e. the communication 2 is only quasi-private. 3 Identity Verification andAAA - The concepts of security and privacy rely on 4 accurate and reliable identity verification i.e. that a caller is who they say they are. Identity verification, also known as "authentication", is important to enable valid use of 6 data and communication, and to prevent illegal or unapproved access. Reliable identity 7 verification is important in national security, law enforcement, IP ownership, business 8 enterprise, and in individual rights. Example of the importance of identity verification 9 include the following: • To a country's national security, caller identity verification is 11 important in tracing the identity of criminals, spies, terrorists, drug traffickers, and 12 anyone divulging national secrets or threatening national security. It is equally 13 important to be able to identify individuals who are authorized to access, read, or 14 send confidential, secret, or top secret communiques, data, and files. • For law enforcement, caller identity verification is important in 16 identifying individuals or organizations involved in criminal activities such as 17 robberies, arson, drug trafficking, smuggling, prostitution and human trafficking, 18 extortion, blackmail, and other felonies. It is equally important to be able to 19 identify individuals who are authorized law enforcement agents including police, fire, paramedic, park ranger, air marshal, TSA and airport security, port authority, 21 customs, and coast guard services. 22 • For IP owners such as movie studios, identity identification is 23 important in identifying individuals, organizations, and entities engaged in piracy 24 and the unauthorized distribution of copyrighted material such as music, movies, books, videos, etc. It is equally important in confirming the valid and legal 26 distribution of IP and copyrighted material. 27 • To business enterprises, identity verification of its employees is 28 important to track the intentional or accidental release of material non-public 29 information, to identify those engaged in commercial espionage, to identify individuals engaged in the illegal disclosure of intellectual property, and those 31 committing other crimes such as fraud or personal use of company

1 communication. It is equally important in confirming the identity of those to 2 which company confidential information is available, and specifically to authorize 3 which specific types of data they have access. For example, the engineering 4 department of a company should not have access to the personnel records of the marketing department in order to compare how much the marketing staff is being 6 paid. 7 • To individuals, identity verification is important to insure a caller's 8 "privacy" by confirming the person or persons with whom you are 9 communicating are not imposters. So the role of identity verification is to confirm a person's identity, i.e. to 11 authenticate they are who they claim to be, and to identify, block, and ultimately 12 apprehend those misrepresenting their identity. Authentication is the first "A" of the 13 triple-A security model, or AAA standing for "authentication, authorization, and 14 administration". Numerous methods such as a PIN code, passwords, fingerprints, tokens, and query response methods may be used to verify a person's identity and to authenticate 16 they have an account on the system. 17 Once authenticated, a valid user's identity is then used to determine the access 18 rights and privileges to communiques, data, files, system operation, etc. These privileges 19 and access rights collectively are referred to as a user's "authorization" as granted by the system. i.e. an authenticated user can only access the communications, data, files and 21 system features for which they are authorized. Authorization is therefore synonymous 22 with "privileges" or "access". 23 The third "A" in AAA stands for administration. Administration is the 24 bookkeeping of recording authorized access to the network and files, e.g. for the purpose of pay-per-use billing administration, and to monitor and report attempts for unauthorized 26 access to the network, files, and system operation. Administration is also important is 27 tracking changes in security credentials, PINs, passwords, etc. needed in the 28 authentication operation. 29 A network's ability to perform AAA procedures is paramount to insure privacy and to prevent corruption of the network from unauthorized users or network operators. 31 Any network unable to insure the identity of its users can be corrupted for illegal

1 purposes. Network corruption by unauthorized users is unavoidably problematic in OTT 2 communication because no means exist is to validate caller identity. Unauthorized access 3 and network communication by unidentified users, i.e. anonymity, is a significant risk in 4 modern communication. Anonymity - The principle of anonymity in communication is the practice of 6 intentionally hiding a caller's identity in order to communicate without traceability. A 7 nearly symbolic example of anonymous communication is a payphone. In a payphone 8 call, payment is by, untraceable cash, the payphone number is public, and anyone can use 9 the phone, meaning the identity of the caller is not known and there is no certain means to determine if a caller is who he or she claims to be. Because the phone number is unlisted, 11 no individual owns the number and (except through sophisticated voice recognition 12 software) there is no way to identify the caller's identity. In the case of a registered 13 device such as cell phone, the identity of the device's owner can be traced through the 14 phone number, but the identity of the caller may still remain unknown. For example, the phone may be stolen, or a pay-per-use SIM card may be used to obscure the caller's true 16 identity. Alternatively, a notebook, tablet, or cell phone can be connected through WiFi 17 in a public cafe, offering similar anonymity as any public payphone or phone booth. 18 Some OTT carriers have chosen to operate a VoIP phone service as a payphone, 19 with no identity verification of its subscribers. For example in a recent online report (http://money.cnn.com/2015/11/17/technology/isis-telegram/) CNN Money revealed "An 21 app called Telegram is the'hot new thing among jihadists". Research confirms the 22 Telegram application was instrumental in ISIS terrorists secretly planning its attack on 23 Paris. In the article "Telegram founder knew Isis was using the app to communicate 24 before Paris attacks," (http://www.independent.co.uk/life-style/gadgets-and tech/news/telegram-knew-isis-communicate-paris-pavel-durov-a6742126.html), 26 Telegram founder Pavel Durov said: 'The right for privacy is more important than our 27 fear of bad things happening, like terrorism'. 28 Another example of privacy and anonymity being used to commit crimes reported 29 in the press is that of BitTorrent - an application and data network often used to illegally download or share copyrighted material. In the news story by CNN Money Tech 31 (http://money.cnn.com/2011/06/10/technology/bittorrentlawsuits/) entitled "50,000

1 BitTorrent users sued for alleged illegal downloads" users were reportedly sued under 2 new anti-piracy laws for illegally downloading the move "The Hurt Locker" and other 3 copyrighted material. The network operator BitTorrent has taken the payphone position 4 that they are not responsible for what people do using their network for their private activities. Freedom of speech advocates support this position while law enforcement and 6 governments, national security, and IP rights advocates abhor this attitude as reckless and 7 irresponsible. Regardless of the politics of the matter, as long as communication systems 8 are incapable of performing caller verification, the discussion to stop anonymous calling 9 is purely academic. Caller verification and authentication is especially important for corporations and 11 business enterprises to control access to company confidential data including intellectual 12 property, engineering developments, product evaluations, manufacturing knowhow, 13 confidential financial reports and projections, business status, sales forecasts, inventory 14 and WIP, quality audits, business and IP contracts, customer lists, employee records, and other trade secrets. When accessing company communications, the access privileges 16 granted any employee, contractor, or officer depends on confirming their identity. In 17 conference calls including investor calls, identity verification is important to confirm who 18 is present on the call and to insure that no one is listening without their need-to-know. 19 Ironically, while caller verification can be used to thwart criminals and deter corporate espionage, the same identity verification is beneficially useful to insure a 21 caller's privacy. If both parties in a call or text chat confirm their identity through some 22 prescribed authentication procedure, imposters have no access to a call or its data, 23 protecting the call from criminal attacks. 24 Lastly, a distinction must be made to distinguish anonymous callers from anonymous calls. An anonymous caller is an individual who disguises their true identity 26 from the network on which they are communicating. An anonymous call, however, does 27 not require the caller has anonymity from the network, just that their true identity during 28 communication is obfuscated in the call data packets. A registered account holder on the 29 SDNP network can, in accordance with this disclosure, place a call or send data using anonymous data transport even though the network knows their identity and phone 31 number. In this way, law-abiding citizens can communicate anonymously without the

1 need to hide their identity from the SDNP network operator. If a caller is engaged in 2 normal private calls, entertainment, or business, their SDNP call remains private and 3 secure even though the network knows their identity as stored in the SDNP name server 4 database. Examples of the need for legal anonymous communication includes global 6 gaming where it is important to protect a gamer's identity, especially that of children. 7 Another case potentially benefitting from anonymity is in vehicle-to-vehicle (V2V) 8 communication to prevent drivers with road rage from exacting revenge by identifying 9 the personal data of other drivers aggravating their driving. In contrast, if a caller is engaged in criminality or other nefarious activity in their communication, law officials 11 can (in accordance with applicable law) gain access to their calls and data transmissions. 12 In this manner the network operator can satisfy the requirements of court orders and 13 subpoenas without exposing the identity or opening the calls of law abiding citizens. 14 In summary, using the disclosed SDNP communication methods, only identifiable SDNP subscribers can place anonymous calls. Unidentified callers have no access to the 16 SDNP network or ability to place anonymous calls. 17 National Security and Privacy - The nature of secure and private communication 18 is further confounded when the roles and laws of governments are considered. Every 19 country asserts their sovereign right to control communications within their borders. With the advent of the Internet and dynamically routed packet switched data networks, 21 however, network surveillance and monitoring faces a plethora of technical and legal 22 challenges. One concern is the issue of monitoring server-to-server network "through" 23 traffic - data packets crossing through a country without ever stopping. Since Internet 24 traffic is dynamically routed, a network operator has no idea what data packets its network of servers is carrying. Any nation can, of course, attempt to intercept and decode 26 this high-volume bulk data, but because of encryption, access without knowing the 27 encryption keys is challenging, especially for real time monitoring. And because the 28 callers may not reside within the country, a particular nation has no jurisdiction to 29 subpoena or demand the encryption keys used to place the call. Such network through data is analogous to radio wave traffic traversing the earth's atmosphere. Even though the 31 radio waves may pass overhead, there is no practical way to stop them. Similarly, except

1 by totally isolating a country's infrastructure from the Internet, there is no realistic way to 2 stop network through-data traffic. 3 A more pragmatic solution to governing communications is to focus monitoring 4 on Last Mile communications, i.e. to intercept and monitor calls and call data where the source and / or destination of a call occurs within a country's borders. This approach has 6 several advantages over intercepting bulk through-data traffic including (i) the magnitude 7 of the data is smaller, i.e. more manageable to analyze, (ii) the last mile communication 8 carrier or network operator is subject to the laws of the country in which it resides (iii) 9 the last mile carrier or network operator may be subpoenaed to surrender any available encryption keys, (iv) the device of the caller must electronically "register" itself to 11 connect to the last mile network and in so doing relinquish information about the caller, 12 and (v) the location of any network connected device can be determined using network 13 addresses, GPS data, or radio signal triangulation. 14 Unlike the legal and technical challenges of enforcing network through-data regulation, the laws governing Last Mile communication and call termination are wholly 16 the right of the nation in which the Last Mile network operator resides. Depending on the 17 privacy laws of a nation, a nation's government can insist on the level of access it 18 requires in Last Mile communications, including combinations of the following: 19 • No right to monitor any data or calls without a court issuing a subpoena based on probable cause. With a court order, the right to secretly 21 monitor any call or data communication. 22 • The right to monitor metadata of any call without a court order. 23 • The right to monitor all calls and data communications without a 24 court order. • The right to intercept, monitor, and as needed, block any and all 26 communications. 27 For example, various governments such as the United States have taken the 28 position they reserve the right to monitor "metadata" of calls without a court order. 29 Metadata includes data packet information regarding who is calling who, how long the call lasted, where the callers were located at the time of the call, etc. without actually 31 accessing the call data itself In essence, metadata comprises the data header of an IP

1 packet but not its payload. In contrast, the monitoring of calls and data communication 2 involves access to the payload itself, not just the header data. In such cases where the 3 payload may be encrypted, the government may insist on the network operator supplying 4 it with master encryption keys, should they exist. One issue raised by privacy advocates, is government abuse of power. Specifically should a network rely on a single set of 6 master encryption keys, then relinquishing these keys in response to a court order to 7 enable government surveillance of a specific individual in fact allows the government to 8 monitor everyone's calls, even if the court order was limited to an individual or group. 9 This issue is sometimes referred to as the quandary "who should police the police?" Another consideration concerns the privacy rights of individuals placing an 11 international call. In such cases, the callers should be aware that the relevant laws for 12 government access depends on the location of both callers, i.e. where the two last-mile 13 networks occur. A call from the United States to the China would be subject to US law 14 for the caller in the United States and to Chinese law for the other caller in China. In such situations, call access by one government may be greater than the other. As such, a caller 16 in the country with greater privacy rights may consider their privacy violated by the other 17 country's government, but since they called that country they have no legal grounds for 18 complaint. 19 In the case of communication using the previously disclosed secure dynamic communication network and protocol, interception of through-data in HyperSecure cloud 21 communication of fragmented scrambled dynamically encrypted data packets transported 22 anonymously across the SDNP network is virtually impossible. As such, the privacy and 23 security of a Hyper-Secure call are determined by the device and by Last Mile 24 communication. By adapting disclosed SDNP methods for Last Mile communication, a Last Mile capable of HyperSecure communications and high-integrity privacy can be 26 realized as disclosed herein. 27 Furthermore, mechanisms adjusting the SDNP network's security and privacy 28 settings to accommodate the local law governing Last Mile communication for each 29 nation are disclosed. These methods include safeguards enabling an authorized security authority to monitor communication pursuant to law and court actions without exposing 31 the call data to hackers and cyber-criminals. As such, in HyperSecure Last Mile

1 communication disclosed herein, the use of "back doors" vulnerable to cyber-attacks is 2 not employed. 3 HyperSecure Last Mile Communication Methods & Apparatus 4 To ensure end-to-end HyperSecurity, the application of the methods disclosed previously for encrypted scrambled anonymous fragmented data packet routing within a 6 SDNP cloud must similarly be adapted for communication within the Last Mile. Securing 7 Last Mile communication is particularly problematic because the data may be carried on 8 networks not hosted by the SDNP operator, packet routing may involve conventional IP 9 packet routing, and the last mile network's intrinsic security may be unknowingly compromised by a cybercriminal, possibly complicitous with a last mile network 11 operator. 12 In accordance with this invention, Last Mile communication necessarily involves 13 the transport of IP datagrams outside of the data cloud network using a packet format 14 different from data packets within the SDNP cloud. As illustrated in FIG. 10, the SDNP cloud comprising servers 1201 (represented schematically by soft-switch enabled SDNP 16 nodes Mo,othrough Mo.) transports VoIP, video, text, and data using SDNP datagrams 17 shown in exemplary data packets 1222B, 1222C, and 1222F. An SDNP datagram 18 contains SDNP Layer 3 source and destination addresses, not Internet IP addresses. 19 SDNP addresses differ from IP addresses in that they are recognizable only by SDNP name servers or other servers performing the function of SDNP name servers, and not the 21 Internet's DNS name servers. 22 As described in the above-referenced U.S. Application No. 14/803,869, SDNP 23 packets change dynamically as they move through the network, with updated routing 24 addresses and constantly changing payloads performed in accordance with shared secrets and dynamic "states" (such as time). For example, data packet 1222B sent by node Mo,o 26 comprises Layer 3 SDNP datagram B with unique SDNP addresses and uniquely 27 encrypted payload. Downstream, data packet 1222C output from node Mo, comprises 28 Layer 3 SDNP datagram C with different SDNP addresses and a re-encrypted payload. 29 Several tens of milliseconds later, the same payload reaches node Mo,f which processes the data and forwards data packet 1223G comprising IP datagram G over the Last Mile.

1 Since the changes are performed in accordance with defined states, the original 2 packet data can be recovered by performing a series of anti-function operations executed 3 in the inverse order to which they were performed. For example, the SDNP functional 4 sequence comprising the steps of scrambling, junk insertion (deception), and encryption can be undone by the inverse sequence decryption, junk deletion, and unscrambling, 6 provided the same state used to execute the function is invoked to perform the 7 corresponding anti-function. State data for a packet may be carried as a time, a seed, or a 8 key either embedded in the packet's payload or sent in advance of the packet. Data 9 transport and processing within the SDNP cloud operate using SDNP cloud specific shared secrets and security credentials. The media nodes sharing a common set of shared 11 secrets and security credentials may be referred to as a security "zone". The zone used for 12 security credentials operating within the SDNP cloud cannot be revealed to any user's 13 communication outside the SDNP cloud. As such, all Last Mile communication must 14 comprise a different SDNP security zone than the SDNP cloud. In the example shown, server 1201A and server 1201F hosting corresponding 16 nodes Mo,oand Mof operate as SDNP gateways, i.e. they communicate with devices 17 outside of the SDNP cloud as well as with other intra-cloud SDNP nodes. 18 Communication from these gateways to communication devices outside the cloud 19 represents "Last Mile" communication. Accordingly, the gateway nodes must understand the zone security credentials of both the SDNP cloud and the Last Mile network to which 21 they connect, acting as a translator during packet routing. Semantically, the term Last 22 Mile is an abstraction meaning communication outside the SDNP cloud and does not 23 specifically refer to a distance of one mile. Instead the term Last Mile covers any 24 communication between a client device and the SDNP cloud of any distance, regardless of whether the client device is operating as an SDNP client, i.e. running SDNP 26 application software or firmware, or not. 27 The term Last Mile also applies to both the client device initiating the call and the 28 client device being called. While literally speaking, the caller's data represents the "first 29 mile" of the call rather than the last - the distinction between first and last miles is arbitrary. Specifically, in any duplex conversion or in any IP communication "session", 31 the device receiving the call necessarily responds to the call or session request by sending

1 a reply to the caller. In any two-way communication, the first mile connection is therefore 2 invariably functioning as the last mile in the reply data path. In essence the first mile for 3 the caller is concurrently the last mile for the response. As such the defined term Last 4 Mile is used to throughout this application to mean both the first mile and last mile, regardless of which device initiated the call or communication session. 6 Communication outside of the SDNP cloud to any device other than an SDNP 7 Client necessarily occurs using IP datagrams and not by SDNP datagrams. For example, 8 referring again to FIG. 10, data packet 1223A comprises "IP datagram A" constructed 9 using an SDNP payload with an IP address, not a SDNP address. Similarly, IP datagram G comprises a data packet 1223G containing a SDNP payload routed using an IP address. 11 The IP source and destination addresses represent any IPv4 or IPv6 address recognizable 12 by the network on which it is routed. The IP addresses may comprise Internet addresses 13 recognized by the Internet's DNS servers or alternatively may comprise NAT addresses 14 used for routing across local networks defined by a local network service provider. Since the hardware and firmware used in Last Mile communication may vary 16 significantly and may include phone lines, fiber communication, cable TV networks, 3G 17 and 4G radio networks, microwave communication towers, and satellites, analysis of Last 18 Mile communication must be considered for a variety of Layer 1 physical networks and 19 their corresponding Layer 2 data link formats employed. Formats may, for example, include analog (POTS), Ethernet, WiFi, 3G, 4G/LTE, and DOCSIS3. The corresponding 21 security and privacy capability of each Last Mile implementation is considered on a case 22 by-case basis in the following section on SDNP "call out" communication. 23 SDNP Call Out Over Unsecured Lines - As a term of art, any call leaving a 24 defined network to be transported across a separate (and generally dissimilar) network is commonly referred to as a "call out", a term meaning data or voice leaves one network to 26 be transported on another. For example, communication within between clients running 27 Skype applications is commonly referred to as a Skype call, but placing a call from a 28 Skype client to a regular or cell phone number is referred to as a Skype call out feature, 29 or "Skype out" call. In general, call outs to regular phones involve some additional cost, either as a subscription or as a pay-per-use fee.

1 In the context of this disclosure, communication from the SDNP cloud over an 2 unsecured Last Mile connection to any device other than an SDNP Client is herein 3 referred to the defined term "SDNP Call Out". FIG. 11 schematically represents two 4 examples of SDNP Call Out routing onto an unsecure Last Mile. In the upper example communication occurs using analog signals to an analog device such as a telephone or 6 payphone 6A. In such cases the SDNP gateway has to include a digital-to-analog 7 converter. Otherwise, a modem or conversion device may be added at the gateway. The 8 information is carried by an analog signal 1221, not a data packet. Analog phone signals, 9 while efficient for carrying voice, are not well equipped for high-speed data communications. 11 In the lower case, the SDNP Call Out occurs across a digital network to any 12 digital device (such as cell phone 32) not enabled as an SDNP client, i.e. not enabled with 13 SDNP software or firmware. In such cases, data packet 1223 carries the call or data, 14 generally using in accordance with Internet protocol, i.e. IP packet format consistent with the 7-layer OSI model. The IP datagram includes IP or NAT addresses in its source and 16 destination address fields, and IP or VoIP data as its payload. The digital path may 17 involve various forms of digital data such as Ethernet, WiFi, or 4G/LTE that vary along 18 the Last Mile connection. 19 In either of the exemplary schematics, because the Last Mile communication data is carried outside of the SDNP network over an unsecured communication channel or 21 network, then the call is not secure and is subject to hacking, spying, wire tapping, and 22 other cyber assaults. As described in the background section of this application, 23 unsecured lines and connections for the Last Mile, whether twisted-pair copper wires, 24 coax cable, fiber, Ethernet, WiFi, cellular, or satellite, are intrinsically not secure unless special security methods such as encryption are inserted in the end-to-end data path. The 26 security of the most secure data cloud or VPN is therefore compromised by its weakest 27 link - in this example, the Last Mile. Even encryption does not guarantee security, 28 especially on a single well-defined electrical, microwave, or radio wave connection. In 29 addition to lacking security, the schematic examples do not include any mechanism for identity verification. Incapable of authentication, the Last Mile has no guarantee of

1 privacy. The exemplary schematics therefore represent unsecure Last Mile networks 2 lacking caller privacy. 3 FIG. 12 illustrates a SDNP gateway 1201A executing a SDNP call-out to an 4 unsecured Last Mile lacking privacy, connecting to a public switched telephone network or PSTN gateway 1A over digital network service provider NSP hosted wired or fiber 6 link 24. The PSTN gateway 1A then is routed to a plain old telephone system POTS 7 switch 3 over an analog communication connection 4. POTS switch 3 then places 8 conventional phone calls over twisted copper pair wire 7 to home phone 6, to cordless 9 phone system 5, or to payphone 6A. The entire Last Mile is neither private nor secure. Although communication of data packet 1222A containing SDNP datagram-A uses 11 SDNP addressing and SDNP payloads within the SDNP network, once the data enters the 12 Last Mile the HyperSecurity benefits are lost. For example, data packet 1223B 13 comprising IP datagram B carried by NSP network hosted wired or fiber link 24 employs 14 conventional IP addressing recognizable by Internet DNS servers and contains a conventional IP payload sniffable in by any cyber-pirate. Analog lines 4 and 7 are equally 16 vulnerable as they carry simple analog audio signals as analog call data 1221. Although 17 the SDNP gateway can support unsecured non-private call outs, it is ill-advised to 18 connect SDNP secured calls to unsecure Last Mile networks lacking privacy provisions. 19 A slight improvement to the aforementioned unsecured Last Mile implementation can be achieved using identity validation. FIG. 13 schematically illustrates examples of 21 SDNP Call Out routing onto an unsecure Last Mile but with two different types 22 authentication. The upper example illustrates a SDNP Call Out from SDNP gateway 23 1220A over an analog or POTS line to a business office desktop phone 9. As shown, 24 operator 1225 performs authentication manually to confirm the account holder's identity and to confirm their account ID. Although authenticated, the call carried by analog sound 26 1221 is unsecure, and remains private only if no secrets or account information is 27 revealed aurally in the conversation, i.e. if no secrets are revealed the information is 28 private but if information is revealed then the communication is no longer private. As 29 such, the term quasi-private is used herein to refer to authenticated communication over unsecure lines, i.e. conditionally private communication.

1 The lower schematic illustrates an SDNP call-out from SDNP gateway 1220A 2 onto an unsecured digital Last Mile. Data carried by IP datagram 1223 to an electronic 3 device such as desktop PC 36, while unsecured, can be authentication using an electronic 4 ID verification method such as token 1226 to which a cyber-attacker does not have access. Because the line is unsecure and sniffable, care must be taken in the digital 6 dialogue not to reveal account numbers or confidential data. 7 Specific examples of quasi-private unsecured calls are shown in several examples 8 to follow. In FIG. 14, identity verified unsecured Last Mile communication is illustrated 9 between the SDNP network and an office desktop phone 9, for example a private banker's phone. The account holder's call, if placed internationally for example, would 11 be routed across the globe using HyperSecure communication in the SDNP network and 12 finally connected to the Last Mile as an SDNP call out through SDNP gateway 1201A. 13 The long distance portion of the call occurs using dynamically changing SDNP 14 datagrams such as data packet 1222A containing SDNP datagram A with a SDNP payload. Data packet 1222A is then converted by SDNP gateway 1201A from SDNP 16 datagram A into IP datagram B shown by data packet 1223B. Unlike SDNP datagram A, 17 IP datagram B contains a sniffable IP payload. Data packet 1223B is transported by 18 network service provider (NSP) operated wired or fiber link 24 to public switched 19 telephone network or PSTN gateway 1A. This gateway in turn is connected to company switchboard 8A over POTS line 4 carrying analog call 1221. Company switchboard 8A 21 connects to desktop phone 9 over analog private branch exchange or PBX line 7A to 22 desktop phone 9 and also to personal authentication operator 1225. During the call, the 23 account holder contacts the private banker on desktop phone 9 but before they can 24 commence engaging in any transactions, personal authentication operator 1225 joins the call to confirm the identity of the caller, and thereafter leaves the call so that the caller's 26 privacy is maintained. Because the call is not secure however, care must be taken by both 27 the private banker and the account holder not to verbally reveal confidential information 28 such as account numbers, passwords, or PINs. As such the call is quasi-private, i.e. 29 conditionally private. In FIG. 15, identity verified unsecured Last Mile communication is illustrated 31 between the SDNP network and desktop computer 36. In a digital communication

1 session, desktop computer 36 communicates to SDNP gateway 1201A using IP datagram 2 B carried over several digital mediums. In the first leg, Ethernet 106A carries data packet 3 1223D comprising IP datagram B from desktop computer 36 to Ethernet based local 4 router 27B. The Ethernet local router in turn communicates to network router 27 over Internet service provider (ISP) wired or fiber link 24A using data packet 1223C 6 comprising IP datagram B. Network service provider line NSP operated wired or fiber 7 link 24 carries data packet 1223B comprising IP datagram-B on the final leg of the Last 8 Mile between network router 27 and SDNP gateway 1201A. Because IP datagrams are 9 employed, the Last Mile is unsecure. Digital methods for ID verification such as login window 1227 and security token 1228 can be used for authentication to insure 11 communications remain quasi-private. These digital authentications must be limited to 12 single use to prevent use by imposters. For example, once a token generates a number 13 and it is used to gain access, the combination is no longer valid for use so if a hacker 14 intercepts the token, it's useless because it expired and is no longer valid. Other examples of identity-verified unsecured Last Mile communication are 16 illustrated in FIG. 16, where SDNP gateway 1201A communicates as a SDNP call out 17 with point of sale (POS) terminal 38 and gas pump POS terminal 38A. Last Mile 18 communication as shown is an amalgamate of digital and analog connections including 19 NSP wired or fiber link 24 carrying data packet 1223B comprising IP datagram B to network router 27, followed by wired or fiber link 24A carrying IP datagram B within 21 data packet 1223C to PSTN bridge 3A, and POTS or analog lines 30B carrying digital 22 PCM (pulse code modulated) data as analog calls 1221A connected to point of sale (POS) 23 terminal 38 and gas pump POS terminal 38A. Authentication in financial transactions is 24 based on bankcard data 1229 which may include smartcard integrated circuit based electronic validation and by dynamic PIN 1228. Authentication involves confirmation 26 with financial institution 1230 connected to the SDNP network either through SDNP 27 gateway 1201A or through a different Last Mile. 28 HyperSecure Last Mile Communication - By adapting techniques of the secure 29 dynamic communication network and protocol, HyperSecure communication can be achieved over the Last Mile. To facilitate HyperSecurity, the connected device must 31 execute SDNP code as a "SDNP client". The SDNP client comprises operating

1 instructions, shared secrets, and SDNP connectivity information, hosted on the connected 2 communication device. The SDNP client may comprise software running on an operating 3 system, firmware running on a microcontroller or programmable IC, or in a dedicated 4 hardware or integrated circuit. FIG. 17 schematically represents an example HyperSecure communication over the Last Mile using a "SDNP connection". As shown, 6 SDNP gateway 1201A connects to a device running a SDNP client, in this example 7 SDNP app 1335 running on desktop computer 36. The SDNP client is hardware and 8 operating system specific. For mobile devices separate apps are required for different 9 mobile device platforms using Android, iOS, and Windows Mobile. Similarly, distinct OS-specific applications are required for notebooks, desktop PCs, and servers including 11 Windows 10, MacOS, Unix and Linux, etc. Hardware hosting of SDNP clients in devices 12 lacking higher-level operating systems such as POS terminals, hotspots, IoT, etc. must be 13 adapted to the programmable device executing the code. Programmable integrated 14 circuits frequently require programming in a chip-specific development environment unique to the IC's vendor, e.g. Qualcomm, Broadcom, Intel, AMD, NVidia, Microchip, 16 etc. 17 Because the SDNP gateway 1201A and the SDNP app 1335 communicate using a 18 SDNP payload 1222, caller identities and call payloads are incomprehensible to packet 19 sniffing, specifically the SDNP payload 1222 contains source and destination SDNP pseudo-addresses unrecognized by DNS servers and the payload comprises SDNP data 21 that may be scrambled, fragmented, mixed with junk data insertions, and dynamically 22 encrypted. SDNP payload 1222 is embedded in IP datagram 1223, which directs routing 23 over the Last Mile using IP addresses or NAT addresses of the cellular, cable, or ISP 24 carrier's network used for Last Mile connectivity rather than an SDNP address. Another aspect of SDNP based HyperSecure Last communication, is that any 26 SDNP client is intrinsically capable of authentication and identity verification. Privacy 27 features, therefore are not based on the network's ability to achieve privacy to support 28 AAA, but whether not the client software or firmware are designed to facilitate the 29 verification process. Because any HyperSecure Last Mile is identity verification capable, it should be understood that the following HyperSecure Last Mile examples apply both to 31 private and non-private secure communication. So unlike unsecure last mile networks

1 with quasi-privacy features, private communication over a HyperSecure Last Mile is 2 determined by the SDNP client, not the network, and capable of supporting any degree of 3 single-factor or multi-factor authentication procedure desired by the client. 4 Specific examples of HyperSecure calls are shown in several examples to follow. In FIG. 18, HyperSecure Last Mile communication is illustrated between the SDNP 6 network and various cellular mobile devices with a WiFi Last Link. As shown, data 7 packet 1222A comprising SDNP datagram A and containing a SDNP payload is 8 converted by SDNP gateway 1201A for Last Mile communication into data packet 9 1223B comprising IP datagram B also containing a SDNP payload. Since the HyperSecure Last Mile utilizes different shared secrets, numeric seeds, encryption keys, 11 and other zone-specific security credentials than the SDNP cloud employs, the SDNP 12 payload in IP datagram B is different than the SDNP payload in SDNP datagram A. In 13 other words, SDNP gateway 1201A translates the SDNP datagrams into IP datagrams by 14 changing the payload from one security zone to another, and by embedding SDNP routing information as source and address SDNP addresses not recognizable by DNS 16 servers. 17 This zone-specific SDNP payload is next wrapped in an IP datagram packet with 18 an IP header containing last mile network specific IP addresses, either NAT or Internet 19 addresses, to facilitate packet routing between SDNP gateway 1201A and the communicating devices, i.e. tablet 33 and cell phone 32 acting as SDNP clients. Because 21 the intermediate devices in Last Mile routing are not SDNP clients, the construction of 22 the SDNP payload within IP datagram B remains fixed as it travels across the Last Mile. 23 In other words, data packets 1223B, 1223C, and 1223D are identically constructed 24 datagrams, all comprising SDNP datagram B with identical SDNP payloads - payloads that do not change as the packets hops from device to device along the Last Mile. Simply 26 summarized, only an SDNP network node or an SDNP client can reconstruct an SDNP 27 payload embedded in a Level 3 datagram, whether an IP datagram or a SDNP datagram. 28 As shown, data packet 1223B comprising IP datagram B is carried by NSP 29 operated wired or fiber link 24 to network router 27, followed by data packet 1223C also comprising IP datagram B carried by ISP operated wired or fiber link 24A to WiFi router 31 26. WiFi router 26 then facilitates Last Link communication using data packet 1223D

1 comprising IP datagram B over WiFi link 29 with mobile devices such as cell phone 32 2 and tablet 33, both running SDNP app 1335A. As such, these devices function as a SDNP 3 client capable of interpreting the data contained within data packet 1223D comprising IP 4 datagram B, including decrypting, de-junking, unscrambling and mixing the payload's content with data fragments from other data packets to recreate the original message or 6 sound. 7 In FIG. 19, HyperSecure Last Mile communication is illustrated between the 8 SDNP network and various cellular mobile devices with a cellular radio Last Link. As 9 shown, data packet 1223B comprising IP datagram B is carried by NSP operated wired or fiber link 24 to network router 27, followed by data packet 1223C also comprising IP 11 datagram B carried by mobile network operator (MNO) wired or fiber link 24B to 12 cellular base station 17 to create cellular network 25. Cellular base station 17 then 13 facilitates Last Link communication using data packet 1223D comprising IP datagram B 14 over 3G, 4G/LTE cellular link 28 with mobile devices such as cell phone 32 and tablet 33, both running SDNP app 1335A. 16 As in the previous example, because the intermediate devices in Last Mile routing 17 are not SDNP clients, the construction of the SDNP payload within IP datagram B 18 remains fixed as it travels across the Last Mile. In other words, data packets 1223B, 19 1223C, and 1223D are identically constructed datagrams, all comprising SDNP datagram B with identical SDNP payloads - payloads that do not change as the packets hops from 21 device to device along the Last Mile. 22 In FIG. 20, HyperSecure Last Mile communication is illustrated between the 23 SDNP network and various tethered (non-mobile) devices with Ethernet Last Link. As 24 shown, data packet 1223B comprising IP datagram B is carried by NSP operated wired or fiber link 24 to network router 27, followed by data packet 1223C also comprising IP 26 datagram B carried by Internet service provider ISP wired or fiber link 24A to Ethernet 27 router 103A. Ethernet router 103A then facilitates Last Link communication using data 28 packet 1223D comprising IP datagram B over Ethernet 106A with tethered devices such 29 as desktop computer 36 running SDNP app 1335C and desktop phone 37 running SDNP firmware 1335B. Absent SDNP network nodes or SDNP clients in the Last Mile, data 31 packets 1223B, 1223C, and 1223D are identically constructed datagrams, all comprising

1 SDNP datagram B with identical SDNP payloads - payloads that do not change as the 2 packets hops from device to device along the Last Mile. 3 In FIG. 21, HyperSecure Last Mile communication is illustrated between the 4 SDNP network and cable service clients. As shown, data packet 1223A comprising IP datagram B is carried by NSP wired or fiber link 24 to cable CMTS 101, the command, 6 communication and content distribution center of a cable operator. Such cable operators 7 provide broad services such as cable TV, pay-per-view, phone services, Internet 8 connectivity, business services, and more. The CMTS 101 head unit then connects to 9 clients via cable 106 using fiber or coax modulated in accordance with DOCSIS3 and trellis formatting (described in the background section of this disclosure) to optimize 11 bandwidth and real time services. Transparent to clients, the cable operator may maintain 12 the datagram format or alternatively package the IP datagrams into a proprietary 13 datagram format. These data packets, herein referred to as CMTS datagram C, use cable 14 specific NAT addressing, and encapsulate the SDNP payload as n nested payload within the data packet 1224C for delivery on cable 106. 16 As shown, cable CMTS 101 routes CMTS datagram C to cable modem 103, 17 which in turn extracts the payload data packet 1223B comprising IP datagram B with the 18 unaltered SDNP payload for Last Link delivery. The Last Link to SDNP client enabled 19 devices may occur in several formats including over Ethernet 106A to desktop computer 36 running SDNP client app 1335C, or over copper twisted pair 7 to cordless phone 5A 21 running SDNP client firmware 1335B. Cable CMTS 101 also routes CMTS datagram C 22 to cable modem 103, which in turn extracts the original IP datagram, e.g. IP datagram B, 23 and sends it and other video content to cable TV set top box over cable 106. Cable set top 24 box then forwards IP datagram B and content via HDMI-2 107 to UHD interactive TV 39, running SDNP app 1335D. Alternatively SDNP firmware can be hosted by cable TV 26 set top box 102. 27 In FIG. 22, HyperSecure Last Mile communication is illustrated between the 28 SDNP network and a WiFi home network connected via a cable service provider. As 29 shown, data packet 1223B comprising IP datagram B is carried by NSP wired or fiber link 24A to cable CMTS 101, the command, communication and content distribution 31 center of a cable operator. The CMTS 101 head unit then connects using wired or fiber

1 link 24A over coax or fiber to a specific client's cable (WiFi) modem router 100 to 2 create WiFi access point 26. The routing a data packet 1224C may comprise an IP 3 datagram with Internet addresses or contain a proprietary CMTS datagram C with NAT 4 addressing. The routing between SDNP gateway 1201A and the cable (WiFi) modem router 26 represents the wireline leg of the HyperSecure Last Mile. 6 The Last Leg in a home network comprises WiFi link 29 connecting cable (WiFi) 7 modem router 26 to various home devices by data packet 1223D comprising IP datagram 8 B wirelessly. To facilitate end-to-end HyperSecurity such devices must operate as an 9 SDNP client either using software or firmware loaded onto the device. For example notebook 35 and desktop computer 36 operate as SDNP clients using computer app 11 1335C, cell phone 32 and tablet 33 operate as SDNP clients using mobile app 1335A. IoT 12 devices, in this case refrigerator 34K are able to operate as an SDNP client if their control 13 system is loaded with SDNP firmware 1335E. If however, such devices do not or cannot 14 embed the SDNP client's software, end-to-end security must be achieved by other means. Identity-Paired Last Link Security - In cases when a connected device cannot act 16 as an SDNP client, HyperSecurity cannot be guaranteed end-to-end. In such case, the use 17 of a SDNP remote gateway can extend HyperSecure communication to cover the Last 18 Mile of communication except for the Last Link. If the Last Link, the portion of the Last 19 Mile connecting directly to a communication device, is not enabled as a SDNP host, then Last Link security must be insured through the local area network (LAN) used to 21 facilitate Last Link communication. FIG. 23 schematically represents the use of SDNP 22 remote gateway 1350 in Last Mile communication. SDNP remote gateway 1350 23 comprises any communication device enabled by SDNP firmware 1335H to function as a 24 remote gateway. As such, a SDNP connection between SDNP gateway 1201A and SDNP remote gateway 1350 comprises IP datagram 1223A including IP or NAT source and 26 destination addresses and SDNP payload 1222. The SDNP payload 1222 includes a 27 SDNP address not recognizable by DNS servers and a nested SDNP payload using Last 28 Mile zone specific security credentials. This SDNP connection is HyperSecure capable of 29 supporting identity verification and caller privacy. Between SDNP remote gateway 1350 and any connected device other than a 31 SDNP client (such as desktop computer 36), communication is performed by a local area

1 network or LAN connection such as Ethernet, WiFi or other protocols. Security is 2 facilitated by LAN security protocols and device pairing between the communication 3 device and the SDNP remote gateway. Device pairing is the process whereby an 4 authentication sequence between two communicating devices establishes the identity of the two devices, preventing unauthorized access. 6 In FIG. 24, the use of an SDNP enabled router 1351, i.e. a router running SDNP 7 firmware 1335H performs the function of a remote SDNP gateway. This gateway 8 converts data packet 1223A comprising IP datagram A into data packet 1223B 9 comprising IP datagram B. Although SDNP firmware 1335H can interpret SDNP payload contained in IP datagram A, the connected devices are not SDNP clients. Instead SDNP 11 router 1351 converts SDNP payload into a conventional IP payload. Unless additional 12 security methods are introduced in a device this Last Link is unsecure. For home use, this 13 unsecure device connection is often not a concern because the Last Link occurs inside the 14 home. Unless a hacker physically invades a house to connect a wiretap, such wireline connections are not sniffable. Examples of wired in-home Last Links to non-SDNP 16 devices include Ethernet 106A, shown by example connected to desktop computer 36 and 17 to modem 103C or HDMI-2 connected to a TV 39. 18 Since the SDNP connection and HyperSecure communication extends only to 19 SDNP router 1351, the Last Link must rely on authentication and encryption to achieve security on wireline connections. For Ethernet such security can utilize any number of 21 security methods (http://www.computerweekly.com/feature/iSCSI-security-Networking 22 and-security-options-available) including iSCSI operating on Layers 1 through Layer 3, 23 such as virtual local area network operation or VLAN utilizing encryption among 24 authenticated devices. Alternatively security can be achieved using Layer 4 to Layer 6 methods using the "IP Security" or IPSec framework. Originally developed for data 26 storage and promoted by Cisco as an industry standard, IPSec offers two security modes. 27 In the "Authentication Header" mode, the receiving device is able to authenticate the 28 sender of data. In this mode, the data field is encrypted but the header uses a recognizable 29 IP address. Encapsulating Security Payload (ESP), also known as tunnel mode, the entire IP packet, including the IP header is encrypted, and nested in a new unencrypted IP

1 packet so that routing can function properly and the packet can reach its correct network 2 destination. 3 In either case, security relies on authenticating devices to allow them to connect to 4 the network. In home networks, e.g. personal networks connecting to computers, shared storage drives, IoT and other device connections, network-connected hardware does not 6 change frequently. In such cases, authentication essentially involves a registration process 7 of a device gaining access to a network or router. Rather than identifying a specific user's 8 identity, this type of authentication is between devices, i.e. device-to-device, generally 9 using some device tag, name, or ID number to identify and recognize the devices approved for connection. Establishing a network connection involves a setup phase when 11 the devices are first introduced to one another and approved by the user for connection, 12 followed by an automated authentication sequence each time a wireline device is 13 physically connected to the other or for WiFi whenever the two devices come within 14 range of one another. The setup phase, referred to herein as identity pairing, may also be referred to as device registration, device bonding, device pairing, pairing, or pair 16 bonding. A similar process is used with devices to connect a Bluetooth headphone to a 17 cell phone or to pair bond a Bluetooth cell phone to a car's hands free audio system. 18 Protocols include challenge handshake authentication protocol or CHAP, Kerberos V5, 19 Simple Public-Key Generic Security Services Application Programming Interface (GSSAPI), Secure Remote Password (SRP), and Remote Authentication Dial-In User 21 Service (RADIUS). Some methods such as RADIUS rely on encryption methods that 22 have been broken, but still are used in combination with other techniques. 23 While Ethernet communication protects identity-paired devices such as Ethernet 24 modem 103C, the output of the modem, comprising analog telephone signals conducted over copper twisted pair conductors 7 to cordless phone 5A and to desktop phone 37, the 26 Last Link is not secure. Moreover, the communication format of cordless phone 5A is not 27 secure and subject to interception and monitoring. For this reason, the use of home 28 phones in secure communication is ill advised. 29 The distribution of video content is another subject of interest in security. For example in the communication of SDNP router 1351 to HDTV 39, a video 31 communication format such as High Definition Multimedia Interface (HDMI),

1 DisplayPort (DP), Digital Visual Interface (DVI), and less popular Gigabit Video 2 Interface (GVIF), or Unified Digital Interface (UDI) commonly comprises the physical 3 connection to the HDTV or display monitor. Originally the security of this connection 4 and its data was the concern of movie studios and content providers, with a focus on preventing the illegal copying and distribution of copyrighted material. One security 6 protocol developed by Intel Corp. for maintaining security of the video link is High 7 bandwidth Digital Content Protection or HDCP (https://en.wikipedia.org/wiki/High 8 bandwidthDigitalContentProtection). Originally the system was intended to prevent 9 HDCP-encrypted content from being played on unauthorized devices. The system checks for authorization of the TV receiver or display before sending the content. DHCP 11 therefore uses authentication to prevent non-licensed from receiving data, it encrypts data 12 to prevent eavesdropping of information, and key revocation of compromised devices. 13 With HDCP content flow from a modem to the TV can be secured by 14 authentication, i.e. using identity pairing. With advent of smart TVs, however data flow is bidirectional. As a means to facilitate upstream data flow, i.e. from the TV to the modem 16 or set top box, starting at revision 1.4, HDMI now embeds a high-speed bidirectional data 17 channel known as HEC or HDMI Ethernet Channel. This data channel means HDMI 18 connected devices can send and receive data via 100MC/sec Ethernet, making them ready 19 for IP-base application such as IP-TV. The HDMI Ethernet Channel allows Internet enabled HDMI devices to share an Internet connection via the HDMI link, with no need 21 for a separate Ethernet cable. As such secure communication can be facilitated over 22 HDMI using the same security protocols and identity pairing available in Ethernet. 23 In FIG. 25, the use of an SDNP enabled WiFi router 1352, i.e. a WiFi router 24 running SDNP firmware 1335J performs the function of a remote SDNP gateway. This gateway converts data packet 1223A comprising IP datagram A into data packet 1223B 26 comprising IP datagram B. Although SDNP firmware 1335J can interpret SDNP payload 27 contained in IP datagram A, the connected devices are not SDNP clients. Instead SDNP 28 WiFi router 1352 converts SDNP payload into a conventional IP payload and wirelessly 29 communicates with the connected devices using WiFi access point 26 to facilitate communication over WiFi link 29. Unless additional security methods are introduced in a 31 device this Last Link is unsecure. In the case of WiFi communications in the home or

1 office, security is a concern because the data packets can be sniffed from a distance. 2 Examples of WiFi connected home and office devices include desktop computer 36, 3 notebook 35, tablet 33, cell phone 32, speakers 34B, printer/scanner 34A, and shared data 4 drive 34C. Security between the SDNP gateway, i.e. SDNP WiFi router 1352, and the 6 connected device is achieved using any number of industry standard protocols such as 7 WiFi Protected Access WPA-II or WPA2 (IEEE 802.1li-2004) a replacement for the 8 older WPA and its unsecure predecessor WPE. WPA2 communication is protected using 9 CCMP, an acronym for Counter Mode Cipher Block Chaining Message Authentication Code Protocol based on AES processing with a 128-bit key and a 128-bit block size. 11 CCMP provides data confidentiality, requires authentication, and sets access control. 12 Authentication involves identity pairing at setup. Re-pairing must be performed 13 manually. CCMP security, while good, is not HyperSecure, lacking anonymous data 14 packets and dynamic nature of the SDNP communication provided from a SDNP client. In the FIG. 26 example of IoT connected devices in a home network, the use of 16 an SDNP enabled WiFi router 1352, i.e. a WiFi router running SDNP firmware 1335J 17 performs the function of a remote SDNP gateway. This gateway converts data packet 18 1223A comprising IP datagram A into data packet 1223B comprising IP datagram B. 19 Although SDNP firmware 1335J can interpret SDNP payload contained in IP datagram A, the connected IoT devices are not SDNP clients. Instead SDNP WiFi router 1352 21 converts SDNP payload into a conventional IP payload and wirelessly communicates 22 with the connected devices using WiFi link 29 from WiFi access point 26. Unless 23 additional security methods are implemented, this Last Link is insecure - especially since 24 WiFi data packets can be sniffed from a distance. Examples of WiFi connected IoT devices in the home include central heating and air conditioning 34D, lighting 34G, 26 blinds 34F, large appliances 34K, portable and room HVAC 34E, garage doors 34L, 27 home monitoring 34J, and home central security system 34H. 28 Security between the SDNP gateway, i.e. SDNP WiFi router 1352, and the 29 connected device is achieved using any number of industry standard protocols such as the aforementioned WiFi Protected Access protocol WPA2 using CCMP facilitating data 31 confidentiality, requires authentication, and sets access control. WPA2 achieves security

1 using identity pairing, device verification implemented as a Layer 2 protocol. The method 2 is cumbersome involving manual authentication methods. 3 An alternative protocol used for local area networks recently introduced for IoT 4 communications - a proximal network called the AllJoyn framework. The framework discovers devices, creates sessions, and facilitates secure communication. The framework 6 is designed to support IoT device connectivity using numerous Layer 2 transport layers, 7 including WiFi, Ethernet, serial bus communication, and power line PLC. Applications 8 may be based on C, C++, Obj. C, and Java operating on numerous platforms including 9 Linux, Windows, MacOS, Android, iOS, RTOS real time operating system, and open source development environment Arduino. 11 AllJoyn compliant applications authenticate one other and exchange encrypted 12 data to enable end-to-end application level security. Authentication and data encryption 13 are executed on application Layer 7. Transport layer 2, also referred to as the router layer, 14 transmits security-related messages between application endpoints but does not implement any security logic itself A callback function known as "Auth Listener", also 16 implemented on application Layer 7, facilitates authentication using PINs, passwords, or 17 authentication certificates. Security is achieved using AES128 peer-to-peer encryption. 18 Like WPA, AllJoyn employs identity pairing in an authentication process in advance of 19 executing command and control sequences. Supported authentication methods include a pre-shared key or PSK, secure remote password (SRP) key exchange or logon with 21 username and password. The protocol also supports ephemeral (elliptic curve Diffe 22 Hellman) key exchange (i) with no authentication, (ii) authenticated with a pre 23 exchanged key, and (iii) authenticated with an X.509 ECDSA certificate. 24 The same technology can be applied to business enterprises. In the FIG. 27 example of IoT connected devices in a home network, the use of an SDNP enabled WiFi 26 and Ethernet router 1352Z, i.e. a Ethernet and WiFi router running SDNP firmware 1335J 27 performs the function of a remote SDNP gateway. This gateway converts data packet 28 1223A comprising IP datagram A into data packet 1223B comprising IP datagram B. 29 Although SDNP firmware 1335J can interpret SDNP payload contained in IP datagram A, the connected IoT devices are not SDNP clients. Instead SDNP and Ethernet WiFi

1 router 1352Z converts SDNP payload into a conventional IP payload communicates with 2 the connected devices using both WiFi link 29 and Ethernet 106A. 3 Unless additional security methods are implemented, this Last Link is insecure 4 especially for WiFi data packets that can be sniffed from a distance. Examples of WiFi connected IoT business devices include central heating and air conditioning 34D, lighting 6 34G, surveillance systems 34J, security systems 34H, POS terminals 38, and WiFi 7 Hotspot connected devices such as tablet 33. Business enterprise wireline connected 8 devices depend on the nature of the business. In banking, devices include Ethernet 9 connected ATM machine 38D. In gas stations, devices include by example Ethernet connected gas pump 38A. 11 In summary, Last Link can be secured with non-SDNP clients communicating 12 with a SDNP remote gateway. In this manner the majority of the Last Mile is 13 HyperSecure while the Last Link employs identity paired encrypted security. 14 SDNPBridge Communication - As described above, Last Mile data transport outside the SDNP cloud necessarily employs IP datagrams, i.e. data packets using 16 Internet source and destination addresses, or alternatively using NAT addresses of the 17 network operator. In case of private networks, e.g. those operating within office 18 buildings, or in cooperation with local network service providers willing to host SDNP 19 soft-switches on their servers, it is also possible to utilize SDNP datagrams to achieve HyperSecure communications on portions of Last Mile. 21 As described previously, HyperSecure communication relies on servers to host 22 SDNP soft-switch software or firmware and to communicate using SDNP datagrams and 23 anonymous addresses, not with IP datagrams Within the SDNP cloud, these SDNP soft 24 switch enabled servers are referred to as SDNP nodes, as designated by the SDNP node notation Mo,o, Mo,, Mi,o, Mi,, etc. The above-referenced U.S. Application No. 26 14/803,869 also disclosed communication between multiple independent SDNP clouds 27 connected by SDNP bridges - SDNP gateways routing IP datagrams to other SDNP 28 clouds. 29 The concept of an SDNP bridge can similarly be adapted for portions of Last Mile communication. To create a SDNP sub-network or mini-cloud within the Last Mile, two 31 or more servers must be enabled by SDNP bridge software or firmware. Unlike SDNP

1 client software or firmware operating in an end device, i.e. in a calling device, SDNP 2 bridge operation is used for routing data, not to operate as the final connection. As such, 3 two or more adjacent SDNP bridges can operate as a standalone SDNP bridge network, 4 SDNP mini-cloud or SDNP ad hoc network. The SDNP bridge function, as disclosed, represents a Layer 3 construct analogous to Layer 2 description of bridge mode operation 6 of a WiFi router. Within the SDNP-bridge or SDNP bridge network, communication 7 occurs using SDNP datagrams. Communication to the SDNP-bridge from outside the 8 SDNP-bridge or SDNP bridge network uses IP datagrams with SDNP payloads. 9 Operation of a SDNP bridge within Last Mile communication is exemplified in the schematic representation shown in FIG. 28 comprising an SDNP network with SDNP 11 gateway 1201A, a SDNP bridge comprising SDNP bridge routers 1350 and 1352Z 12 running SDNP firmware 1335H and 1335J respectively, and a connected client device 13 that is not an SDNP client, shown here as notebook 35. As shown, communication 14 between SDNP gateway 1201A and SDNP-bridge 1350 comprises a secure connection utilizing IP datagram 1223A with IP address and SDNP payload. SDNP payload 1222A 16 in turn contains SDNP routing information and secure SDNP payload encoded using zone 17 specific security credentials. HyperSecurity is thereby achieved using the SDNP payload 18 even though IP address routing is employed. 19 Within the SDNP-bridge connection, i.e. between SDNP bridge router 1350 and WiFi-enabled SDNP bridge router 1352Z, HyperSecure communication occurs using 21 SDNP datagram 1222B. SDNP routing information is extracted from the SDNP 22 addressing contained within SDNP payload 1222A. Together, the SDNP-bridge and 23 SDNP connection comprise a HyperSecure wireline leg of Last Mile communication, 24 capable of supporting identity and account verification and supporting privacy. The connection from SDNP-bridge router 1352Z to the non-SDNP client device, 26 i.e. notebook 35, utilizes IP datagram 1223B with an IP address and IP payload over a 27 local area network, either WiFi or Ethernet. Security of this Last Link, albeit not 28 HyperSecure, is secured by any of the aforementioned Ethernet and WiFi security 29 protocols such as iSCSI, IPSec, WPA, AllJoyn, and others. Implementation of the SDNP bridge can occur between any two SDNP enabled 31 devices carried by any number of physical media, meaning SDNP bridging is a Layer 3

1 protocol operating agnostically from Layer 1 PHY and Layer 2 Transport layer 2 realizations. For example, in the topmost schematic shown in FIG. 29A, two SDNP 3 bridge Ethernet routers 1351A each running SDNP firmware 1335H communicate over 4 an Ethernet (wireline) bridge using SDNP datagram 1222. In the center schematic, two SDNP-bridge routers 1352Z, each capable of Ethernet and WiFi communication and 6 running SDNP firmware 1335J, communicate over an WiFi (wireless) bridge using 7 SDNP datagram 1222. In the bottommost schematic, on SDNP-bridge Ethernet router 8 1351A running SDNP firmware 1335H communicates over an Ethernet (wireline) bridge 9 using SDNP datagram 1222 with SDNP-bridge router 1352Z, capable of Ethernet and WiFi communication running SDNP firmware 1335J. In this manner the SDNP bridge 11 comprising two or more SDNP enabled routers can route or distribute SDNP datagrams 12 throughout a building or across a private network even though they operate outside the 13 SDNP cloud in the Last Mile. 14 The SDNP-bridge can be extended to systems utilizing proprietary hardware, such as cable TV systems. For example the topmost schematic shown in FIG. 29B, two cable 16 CMTS "head" servers are modified to run SDNP firmware or software 1335L to operate 17 as cable CMTS SDNP bridges 101 and communicate over an a cable or fiber (wireline) 18 bridge using SDNP datagram 1222. The SDNP-bridge can extend from the CMTS head 19 into the subscriber's home. As shown in the center schematic, cable CMTS SDNP bridge 101 running SDNP firmware or software 1335L communicates using SDNP datagram 21 1222 over cable (coax) bridge to cable TV set-top-box or cable modem 102 running 22 SDNP firmware 1335M. In this manner the SDNP bridge extends HyperSecure 23 communication into the home or office. 24 The SDNP-bridge methods disclosed can also be used to transport data over radio networks. In the bottommost schematic of FIG. 29B, two cellular base stations and radio 26 towers running SDNP firmware or software 1335N function as cellular base station 27 SDNP bridges 17X and 17Y to communicate wirelessly over cellular network comprising 28 cellular bridges 25X and 25Y using SDNP datagrams 1222. In the upper schematic of 29 FIG. 29C, a terrestrial microwave base station running SDNP firmware or software 13350 functions as a ground-to-satellite link SDNP bridge 92C to communicate as a 31 microwave satellite bridge using SDNP datagrams 1222 to an orbiting satellite running

1 SDNP firmware or software 1335P, i.e. to satellite SDNP bridge 93. The satellite then in 2 turn communicates with subscribers or with other satellites. 3 SDNP bridge communication can be adapted to automotive applications 4 employing automobiles as a peer-to-peer ad hoc communication network. In the lower schematic of FIG. 29C, the telematics module in car 1390A running SDNP firmware 6 1335F communicates over an automotive radio bridge using SDNP datagram 1222 with a 7 nearby car 1390B also running SDNP firmware 1335F. Each car enabled with SDNP 8 firmware forms another communication node in a dynamic telematics SDNP bridge 9 network. This communication does not represent information being sent to a particular car or driver but instead forms a communication network able to pass information along a 11 highway even where no cell tower is present locally. 12 The concept of SDNP bridge networks is especially beneficial for communication 13 over large geographies and in transportation and shipping involving cars, trucks, 14 emergency vehicles, trains, airplanes, boats and ocean ships. In particular, to achieve wide area coverage for communication, satellite networks are required. The system 16 typically involves network connectivity with the satellite operator referred to as a satellite 17 bridge or backhaul, and the satellites link to its clients and subscribers also known as 18 satellite distribution. FIG. 30 schematically represents a variety of satellite connections 19 adapted for SDNP HyperSecure communication. As shown SDNP gateway 1201A communicates with terrestrial satellite antenna dish 92C running SDNP firmware or 21 software 13350 using wireline connection 94A carrying data packet 1222A comprising 22 SDNP datagram A and SDNP payload which in turn relays the same SDNP datagram A 23 as data packet 1222B over satellite bridge 95A to satellite 93 running SDNP firmware or 24 software 1335P. Distribution of HyperSecure communication data packets to various clients from 26 SDNP enabled satellite 93 comprises data packet 1222C and SDNP data packet-A 27 containing a SDNP payload. Satellite communication is bidirectional, with the downlink 28 from satellite 93 to terrestrial clients capable of a higher signal strength and faster data 29 rate than the uplink connection. In other words, a satellite can transmit higher data rates and with stronger signal intensity to an earthly client than the client's response. Examples 31 of satellite 93 links to subscribers include satellite link 95B to dish Internet subscriber

1 92G running SDNP firmware 1335T, to sat phone 92F running SDNP firmware 1335S, to 2 satellite antenna array 92H sitting atop high speed train 1360C running SDNP firmware 3 1335G, to satellite antenna array 92E sitting atop ocean vessel 1360B running SDNP 4 firmware 1335R, and to satellite antenna array 92D sitting atop aircraft 1360A running SDNP firmware 1335Q. 6 In the case of large vehicles such as ships, aircraft, and trains, each system 7 connects this HyperSecure satellite communication link to its own internal 8 communication system or local area network. FIG. 31A for example, illustrates a 9 commercial aircraft where satellite antenna module 92D running SDNP firmware 1335X mounted atop the fuselage of aircraft 1360A connects to communication central server 11 1361 running SDNP software 1335Z. Communication central server 1361 links to a 12 variety of systems including instrumentation 1367, data recorder and black box 1368, 13 media storage module 1363, and WiFi router module 1362, optionally running SDNP 14 firmware 1335L. WiFi router module 1362 connects to an array of WiFi antennas 1361 located throughout the airplane to support WiFi Hotspot communications. All 16 communications except for radio based flight control occurs through a common satellite 17 communication link using antenna module 92D shown by example in FIG. 31B. The 18 antenna module includes satellite transmit antenna 1360A, satellite receive antenna 19 1368A, antenna control unit 1369, and 40W voltage regulator 1370. Satellite receive antenna 1368A is smaller than satellite transmit antenna 1360A because the satellite 21 broadcast power and signal strength is greater than the antenna's broadcast strength and 22 uplink capability. 23 Ocean vessel satellite ship communication utilizes multiple bands of satellite 24 communications including high altitude and near earth orbit satellites. FIG. 32 for example, illustrates the use of multiple band communication including Ku band satellite 26 antenna 1383A, and low-earth-orbit satellite antennas 1383B and 1383C. High altitude 27 satellites offer no or limited uplink capability but are able to cover wide areas from great 28 altitudes including geosynchronous orbits. Because of their high altitude, area coverage 29 of each satellite is substantial as shown in map 1384. As shown in map 1385, low earth orbit satellites cover smaller areas, requiring more satellites and therefore a higher cost to

1 cover a broadcast area. Depending on a ship's course, access to low earth orbit satellites 2 may be intermittent based on the satellites' orbital positioning. 3 Since Ku band satellite antenna 1383A is primarily used for distribution of TV 4 and movie content, SDNP security is not generally required. Tracking and positioning is performed by antenna control 1383. Multi-channel data from satellite antenna 1383A is 6 fed into L-band multiswitch 1381 separating signals into fixed video broadcast data 7 routed to TV receivers and tuners 1382 and digital video broadcasting DVB data. Video 8 content is fed into central communication servers 1380. If, however, secure 9 communication is required, Ku band satellite antenna 1383A can be adapted to execute SDNP software. 11 Data from low-earth-orbit satellite antennas 1383B and 1383C running 12 corresponding SDNP firmware 1335U and 1335V relays information from the satellite 13 antennas to central communication servers 1380 running SDNP software 1335Z. Within 14 range of land, the communication system is also capable of communication using 4G/LTE cellular network 25 hosted by cellular base station 17 running SDNP firmware 16 1335N. Communications through servers 1380 are distributed throughout the ship using 17 SDNP WiFi router 1362 running SDNP firmware 1335L. WiFi Hotspot communication 18 of WiFi access point 26 is distributed throughout the ship using WiFi antennas 1361. 19 Communication to SDNP clients such as cell phone 32 running SDNP app 1335 facilitates end-to-end HyperSecure communication. Devices not enabled as SDNP 21 clients, must rely on identity pairing using WAP, AllJoyn, or other security protocols. 22 FIG. 33 illustrates the application of multi-band communication applied to high 23 speed trains. As shown, train data center server 1380 running SDNP software 1335Z 24 connected to SDNP gateway 1201A communicates to high speed train 1360C through multiple PHY connections including satellite microwave 95B, 400MHz radio 1372, and 26 60Ghz microwave 1373. During SDNP communication, SDNP data center 1380 relays 27 data through satellite antenna 92C running SDNP firmware 1335D to satellite 93 running 28 SDNP firmware 1335P. The satellite communicates with train antenna array 1383V 29 connected to server 1361 running SDNP software 1335Y. Alternative communication occurs from SDNP data center 1380 through 400MHz antenna 1381 or 60GHz antenna 31 1382 positioned at regular intervals alongside the train tracks. These satellites also

1 communicate with antenna array 1383B connected to train communication SDNP server 2 1361 running SDNP software 1335Y. Communication received by SDNP server 1361 is 3 then distributed throughout the train by WiFi bridges 1335Z, and to clients as WiFi 4 Hotspots. The function of communication in automotive and in professional trucking is 6 multifaceted involving 7 • Voice communication 8 • Navigation, maps, road information, alerts 9 • Entertainment, Hotspot services, infotainment • Wireless payments, tolls 11 • Emergency services, roadside assistance 12 • Collision avoidance 13 • Dispatcher scheduling (professional, ridesharing) 14 Additional functions are also required for autonomous vehicles, i.e. self-driving cars. Based primarily on older cellular networks such as a CDMA (2.5G) controlled 16 central unit referred to as a "telematics" module, existing automotive systems have been 17 shown to be extremely subject to hacking, cyber-assaults, and privacy attacks. To 18 eliminate this vulnerability the entire network must be secured without significant 19 expense, i.e. installing new network is not fiscally an option. Instead, the security infrastructure must be overlaid atop the hardware network as security methods deployed 21 in Layer 3 through Layer 7. This strategy is compatible with the SDNP Last Mile 22 implementations disclosed herein. 23 FIG. 34 illustrates an exemplary HyperSecure Last Mile connection between a 24 vehicle and the SDNP cloud. As in previous Last Mile connections, the particular data carriers involved transporting packets across the Last Mile may vary dramatically by 26 location. As such, the example is shown to represent HyperSecure communication 27 regardless of the data carriers involved. As shown, SDNP gateway 1201A connects to a 28 network router 67A over a network service provider (NSP) managed wired or fiber link 29 24, converting data packet 1222A comprising SDNP datagram A into data packet 1223A comprising IP datagram B containing a SDNP payload. Network router 67A then routes 31 IP datagram B as data packet 1223B to a cellular base station 17 over a wired or fiber link

1 24A owned or operated by a mobile network operator (MNO). IP data packet B is then 2 wirelessly communicated over cellular network 25 as data packet 1223C comprising 3 SDNP datagram B containing SDNP payload to the telematics module within automobile 4 1390A using cellular link 28, either using 2.5G, 3G, 3.5G, or 4G/LTE depending on the mobile network operator in the region. SDNP firmware 1335F operating within the 6 telematics module then interprets the SDNP payload embedded within incoming data 7 packet 1223C to complete the HyperSecure communication link. As such, an automotive 8 cellular Last Link functions as part of HyperSecure Last Mile communication. 9 As shown in FIG. 35 the telematics module in automobile 1390A then utilizes the secure information for a variety of functions controlled by infotainment interface 1377. 11 Internal WiFi Hotspot 1362D also distributes data packets 1223B and 1223C containing 12 IP datagram B and IP datagram C, respectively. IP datagram B contains a SDNP payload 13 that facilitates end-to-end HyperSecure communication to any SDNP client such as cell 14 phone 32B running SDNP app 1335. IP datagram C using only a conventional IP payload is less secure, but works devices not operating as SDNP clients such as cell phone 32A 16 and tablet 33A. Identity pairing can be used to improve Last Link security for non-SDNP 17 devices using WPA, AllJoyn or other protocols. 18 Another important function in automotive communication is that of vehicle-to 19 vehicle communication also referred to as V2V communication. The purpose of V2V communication is primarily for collision avoidance. But in accordance with the disclosed 21 SDNP methods herein, V2V communications can also function as a HyperSecure ad hoc 22 peer-to-peer network. Such inter-vehicle SDNP communication is illustrated in FIG. 36 23 where automobiles 1390A, 1390B, and 1390C running SDNP firmware 1335F form a 24 peer-to-peer network with one another and with cellular base station 17 connected to SDNP gateway 1201A. Communication among the vehicles can be performed using 26 either IP datagrams or SDNP datagrams. 27 In the case where a SNP client or gateway communicates with a non-SDNP 28 device, communication occurs using IP datagrams. For example SDNP gateway 1201A 29 converts SDNP datagram A with a SDNP payload into data packet 1223A comprising IP datagram B with an embedded SDNP payload. As shown, cellular base station 17 31 communicates to automobile 1390A over a 2.5G or 3G cellular link 28A using data

1 packet 1223B containing IP datagram B with an embedded SDNP payload but is able to 2 communicate to automobile 1390C over a 3.5G or 4G/LTE cellular link 28B using data 3 packet 1223C also containing IP datagram B with an embedded SDNP payload. In this 4 manner the SDNP payload is distributed independent of the network used to carry the data packets. 6 Automobiles enabled with SDNP firmware 1335F may also form an ad hoc peer 7 to-peer SDNP bridge or bridge network. For example, automobile 1390A communicates 8 with automobile 1390B over a V2V radio link 1391A using data packet 1222B 9 containing SDNP datagram C rather than an IP datagram. Similarly, automobile 1390B communicates with automobile 1390C over a V2V radio link 1391B using data packet 11 1222C containing SDNP datagram D, and does not rely on IP datagrams. Regardless of 12 the type of datagram employed, the embedded content remains HyperSecure using SDNP 13 payloads. 14 Another feature of the SDNP ad hoc V2V network is its ability to perform tunneling functions, i.e. passing data through one vehicle to another without the 16 intervening car being able to monitor or interpret the data it is passing through. In the 17 case where cellular link 28B fails because automobile 1390C is out of range, as an 18 alternative path, cellular base station 17 can utilize the SDNP bridge network to reach the 19 same caller, in the example shown through cellular link 28A, V2V radio link 1391A, and finally through V2V radio link 1391B. During data transport, data packets 1223B, 1222B 21 and 1222C, change from IP datagram B to SDNP datagram C and finally to SDNP 22 datagram D. Since the SDNP payload intended for automobile 1390C is uniquely created 23 for the destination automobile, automobile 1390B and its occupants cannot hack or 24 monitor the contents of SDNP datagram C even though are relaying data packet 1222B through the ad hoc network. 26 Aside from conventional Last Mile communication, the same SDNP bridge 27 technology can be used to send large amounts of data using HyperSecurity over long 28 distances, i.e. digital trunk communication. Three such example are shown in FIG. 37, 29 namely microwave trunk 98, fiber trunk 90, and satellite trunks 95A and 95B. While this function may be considered as part of a SDNP cloud, the single data route is similar to 31 that of Last Mile communication, and therefore employs similar methods to insure

1 HyperSecurity. For example, servers 21A and 21B operating SDNP software 1335Z may 2 communicate over microwave trunk 98 via microwave towers 96A and 96B running 3 SDNP firmware 1335W using data packet 1222 comprising SDNP datagrams, or 4 alternatively servers 21A and 21B may communicate directly over fiber trunk 98 also using data packet 1222 comprising SDNP datagrams. In global communication, for 6 example in a transpacific data link, servers 21A and 21B may communicate with satellite 7 93 running SDNP firmware 1335V by means of microwave satellite trunks 95A and 95B, 8 using earth based satellite antennae 92A and 92B, both running SDNP firmware 1335U. 9 As in the fiber and microwave tower examples, satellite trunk communication utilizes data packet 1222 comprising SDNP datagrams. 11 In conclusion, the security and privacy features offered in Last Mile 12 communication depend on the two communicating devices. FIG. 38 contrasts four 13 different combinations representing, in order from bottom to top, increasing security and 14 privacy. In each case, three factors are considered, (i) security, the ability to prevent unauthorized access to the communiques, (ii) ID verification, the ability to authenticate 16 the user and adjust access and privileges based on their identity, and (iii) anonymity, the 17 ability to disguise the identity of callers from surveillance. 18 In the bottom example SDNP gateway 1395 communicates openly with a non 19 SDNP client lacking any security provisions using data packet 1223C comprising an IP datagram with a sniffable IP address and an IP payload. As such the Last Mile connection 21 is not secure and not private. In the example second from the bottom, SDNP gateway 22 1395 communicates with a non-SDNP client offering features of device authorization and 23 identity pairing. Communication is by means of data packet 1223B comprising an IP 24 datagram with a sniffable IP address but using an encrypted payload comprising ciphertext where only the identity-paired device can perform decryption. While the 26 communication is not private or anonymous, it does offer enhanced security, at least for 27 limited durations. 28 The example next to the top illustrates that SDNP gateway 1395 can route 29 communications through any bridge or router 1397 and still achieve HyperSecurity, provided that data packet 1223A comprises a SDNP payload within the IP datagram. The 31 level of security achieved, depends only on the end device, not on the router. In the top

1 example, communication between a SDNP gateway 1395 and a SDNP Client 1396 using 2 data packets 1222 comprising SDNP datagrams with SDNP addressing, i.e. using source 3 and destination addresses not recognizable by Internet DNS name servers, and using 4 SDNP secured payloads, is HyperSecure, offering superior security, full privacy provisions, and anonymous packet routing. 6 HyperSecure Last Mile Packet Routing - Independent of the Layer 1 physical 7 hardware and Layer 2 data link algorithms and methods employed, routing of packets 8 between an SDNP client or SDNP-bridge and the SDNP gateway relies on IP datagrams 9 to carry and route the data packets across the Last Mile. Unlike data routing within the SDNP cloud directed by SDNP signaling servers, the SDNP cloud or its signaling servers 11 do not control IP datagrams traversing the Last Mile. As such, some variability in Last 12 Mile propagation delays is to be expected. Fortunately because the distances of Last Mile 13 communication and the number of possible routes are limited, this uncertainty is small 14 compared to the total end-to-end propagation delay of a global communication. Variation in total propagation delays because of Last Mile variability is estimated to be less than 16 10% of the aggregate delay. 17 FIG. 39 illustrates single route Last Mile communication between SDNP client 18 1400 and SDNP gateway 1401 using fixed IP addresses. IP datagram 1405 includes the 19 IP destination address of Mo,o (the SDNP gateway), and the IP address of the data packet's source Ci, the SDNP client. Last Link communication occurs through a single 21 route 1404 to router 1402A. The data is routed through any number of routers R, e.g. 22 router 1402B, to the SDNP gateway Mo,o. 23 An alternative representation of the Last Mile network connection depicts each 24 communication device as an IP stack representing the PHY, data link, and network connections as OSI Layers 1, 2, and 3. For example, Fig. 40A is an IP stack depiction of 26 single-route last mile HyperSecure communication using static IP addresses. As such, 27 client device comprising SDNP client Ci, establishes a single route Last Mile connection 28 1409 with SDNP gateway 1401 comprising SDNP gateway Mo,o through routers 1402A 29 and 1402B where router 1402A comprises a WiFi router and router 1402B is an Ethernet router. Client device 1400 connects to router 1402A through Last Link 1404 where the

1 PHY Layer 1 physical connection and the corresponding data link Layer 2 of client IP 2 stack 1411 connects to corresponding Layer 1 and Layer 2 in router IP stack 1412A. 3 In turn, router 1402A connects to router 1402B using Ethernet where the PHY 4 Layer 1 physical connection and the corresponding data link Layer 2 of the WiFi router's IP stack 1412A connects to corresponding Layer 1 and Layer 2 in Ethernet router IP 6 stack 1412B. Finally, router 1402B connects to SDNP gateway server 1401 using 7 Ethernet where the PHY Layer 1 physical connection and the corresponding data link 8 Layer 2 of the Ethernet router's IP stack 1412B connects to corresponding Layer 1 and 9 Layer 2 in the gateway's IP stack 1422. In operation, routers carry data undisturbed, so that network Layer 3 IP datagrams, flow from one IP stack to another transparently, 11 specifically from Layer 3 in IP stack 1411 to 1412A, 1412B and finally to 1422. In this 12 manner, the network carries the IP datagrams as single route data across a virtual Last 13 Mile connection 1409 even if the data physically passes through multiple devices 14 In other words, Layer 3 network data flows through the Last Mile independent of the physical connections used to carry the IP datagrams, i.e. Layer 3 Last Mile 16 communication operates agnostically to the underlying Layer 1 and Layer 2 17 implementations used for data transfer. This principle can by represented in simplified 18 form by removing the intermediate nodes from the schematic as shown in FIG. 40B, 19 where client device 1400 and SDNP gateway server 1401 including communication IP stacks 1411 and 1422 transporting data to and from corresponding computing and data 21 storage functions 1410 and 1421. IP datagram 1405 flows over Last Mile connection 22 1409 regardless of the media or the number of routers used in the data packet delivery 23 process. The Last Mile may be therefore be considered as a "data construct", i.e. an 24 abstraction to mean any and all physical means be which the IP datagram is transported between and among devices. The Last Link, however, has more of a physical meaning 26 because the connected device of the caller must be able to connect to the upstream router 27 of the communication link cannot be established. For example, if a caller has a tablet 28 computer with only a WiFi connection and is sitting in a cafe with WiFi, but the caller 29 does not have the WPA password to the WiFi network, then the Last Link cannot be established, and the caller cannot connect to the Last Mile, to the SDNP cloud, or place a 31 call.

1 Another consideration of Last Mile communication is that the payload of IP 2 datagram 1405 contains all the information for upper OSI layers, including the transport 3 Layer 4 data, session Layer 5 data, presentation Layer 6 data, and application Layer 7 4 data. Aside from Layer 4 data needed to select UDP or TCP transport protocols, the remaining data in the IP datagram's payload is specific to the disclosed SDNP 6 communication and cannot be interpreted by routers operating along the last mile unless 7 they themselves run SDNP software or firmware. Accordingly, only the end devices, i.e. 8 the caller or SDNP client and the SDNP gateway, can interpret Last Mile communication 9 even though the Last Mile network itself may comprise an amalgamate of different devices, carriers, and network operators. 11 Although the SDNP payload is secured by numerous secrets including 12 scrambling, fragmentation, junk data insertions and deletions, state dependent formatting, 13 and dynamic encryption, the IP addresses of an IP datagram passing over a Last Mile 14 network, necessarily reveal the source and destination addresses of the client's device 1400 and of the SDNP gateway server 1401. In order to provide a degree of anonymity 16 over the Last Mile, address deception is beneficial, i.e. misdirecting cyber-attackers by 17 dynamically changing the source and destination addresses in the IP datagram. IP 18 deception can be accomplished by dynamically changing the IP address of the caller's 19 connected device, herein referred to as "dynamic client addressing", or by communicating with multiple SDNP gateways, i.e. multi-route Last Mile communication. 21 The first method of IP address deception described involves dynamically altering 22 the source address of sequential data packets. As shown in FIG. 41, IP datagrams A, B, 23 and C sent successively comprise three different source addresses. Specifically, IP 24 datagram A 1405A includes IP source address Ci, IP datagram B 1405B includes IP source address C1,2, and IP datagram C 1405C includes IP source address C1,3. So 26 although the packets entering router 1402A all emanate from SDNP client 1400, the 27 clients source address Ci,n changes dynamically obfuscating the true IP address and 28 appearing to be more than one communicating device. To complete the charade, the 29 MAC address of the communicating device should also change correspondingly with the dynamic source address.

1 This method is illustrated using IP stacks in FIG. 42A where devices 1400, 2 1402A, 1402B, 1401 communicate through corresponding IP stacks 141IN, 1412A, 3 1412B, and 1422 using WiFi and Ethernet but where the SDNP client's network Layer 3 4 identity comprises multiple IP addresses Ci, C1,2, and C1,3. The result is that the sequential data packets entering router 1402A appear to be sent from three different client 6 devices, not one as depicted in the schematic representation of the Last Link shown in 7 FIG. 42B. The shared PHY layer comprises WiFi standard frequencies and the data link 8 layer connecting the devices follows established standards such as 802.1lac or 802.1In. 9 The IP datagrams 1405N sent to router device 1402A along network connection 1408 comprise a fixed destination IP address IP Mo,o and sequential source addresses IP 11 C1,1, IP C1,2, IP C1,3, etc., represented in mathematical notation as IP Ci,n where n = 1, 2, 12 3, . . uniquely identifying each sequential packet. Each sequential IP packet also includes 13 a corresponding payload SDNP 1, SDNP 2, SDNP 3, and so on. Note that although this 14 description refers to each IP address using mathematical shorthand notation IP Ci,n, it is understood that the IP addresses comprise real IP addresses made in accordance with 16 IPv4 or IPv6 international standards and exclude any reserved IP addresses. 17 Another option to enhance security is to employ multiroute packet transport in the 18 Last Mile. In a manner similar to data transport within the SDNP cloud, in multiroute 19 Last Mile communication, audio and sequential data is parsed and fragmented, then divided into separate packets and addressed to different SDNP gateways. An example of 21 multiroute data transport using static IP addresses is shown in FIG. 43 where SDNP 22 client 1400 communicates with multiple gateways 1401A, 1401B, and 1401C. As shown, 23 first data packet 1405A comprises payload SDNP 1 with IP source address Ci, and 24 destination address Mo,o. Data packet 1405A is then routed over Last Link 1404A through routers 1402A and 1402B to SDNP gateway 1401A. In a similar manner a second data 26 packet 1405B comprises payload SDNP 2 with IP source address Ci and destination 27 address Mo,. Data packet 1405B is then routed over Last Link 1404B through router 28 1402C to SDNP gateway 1401B. A third data packet 1405C comprises payload SDNP 3 29 with IP source address Ci and destination address Mo,3. Data packet 1405C is then routed over Last Link 1404C through router 1402D and 1402E to SDNP gateway 1401C.

1 In the path between the client device 1400 and one of the three gateways 1401A, 2 1401B or 1401C shown, the IP datagrams are routed through multiple Last Links 1404A, 3 1404B, and 1404C to multiple routers 1402A, 1402B, and 1402C. These routers may 4 comprise (i) completely independent routers employing identical physical mediums such as WiFi or Ethernet, (ii) multiple router channels in a common hardware device, e.g. 6 multiple trellis channels in a DOCSIS3 cable modem or (iii) different physical mediums 7 for communication, e.g. one routed through WiFi, another through 3G, etc. 8 For example, FIG. 44A illustrates an IP stack depiction of the aforementioned 9 multi-route last mile HyperSecure communication over a common PHY Last Link 1404 using static IP addresses. In operation, SDNP client Ci, communicates with routers 11 1401A, 1402B, and 1402C as a single device connection using common PHY, data link, 12 and network layers. Address deception is performed using successive IP datagrams 13 comprising a static client address IP Ci, but with changing SDNP gateway addresses IP 14 Moo, P Mo,, and IP Mo,3. Packet misdirection may occur algorithmically or randomly. For example, if every 10t datagram sent from client device 1400 is directed to SDNP 16 server 1401C, then the 10 th outgoing datagram from client device 1400 will include a 17 destination address IP Mo,3 and a source IP address IP Ci,. Replies from SDNP gateway 18 server 1401C return to client device 1400 in the reverse path, i.e. with a source IP address 19 IP Mo,3 and destination address IP Ci. As shown, the PHY and data link between the client device 1400 and the routers 21 1402A, 1402D, and 1402C comprises a single medium, e.g. WiFi. Although the Last 22 Link connections are represented as single lines splitting into three it should be 23 understood that the physical connections are all made point-to-point and not by electrical 24 Y connectors used to create parallel wires. Instead the depiction means the connections are to indicate the effect of the connection, i.e. the PHY layer of client IP stack 1411 26 expands one PHY connections into three, i.e. connecting to the PHY layer of IP stacks 27 1412A, 1412C, and 1412D. Functionally, this Last Link operates as a single output to 28 three input expander where one client connects to three router functions, regardless of 29 whether the router functions are contained into one common electronic apparatus or carved into distinct and separate routers. Note that, as shown, Last Link 1404 constitutes 31 a single type of communication media - either cable, fiber, WiFi, Ethernet, or cellular.

1 The remaining portions of the Last Mile however may comprise any media, not 2 necessarily the same as the Last Link. An alternative Last Link involves multiple 3 dissimilar PHY layers connecting to independent routers. Such an implementation, an IP 4 stack executing multi-route last mile HyperSecure communication using static IP addresses over multiple PHY last links is illustrated in FIG. 44B. Specifically client 6 device 1400 operates using a common network Layer 3 interface with a static client 7 address IP Ci, but using separate and distinct Layer 1 and Layer 2 interfaces represented 8 by IP stacks 1411A, 1411B, and 1411C. In operation, IP stack 1411A connects to router 9 1402A over Last Link 1404A directing IP datagram comprising source address IP C, and destination address IP Mo,o traversing router 1402B. Similarly, IP stack 1411B 11 connects to router 1402C over Last Link 1404B directing IP datagrams comprising 12 source address IP Ci and destination address IP Mo,. IP stack 141IC connects to router 13 1402D over Last Link 1404C directing IP datagrams comprising source address IP C, 14 and destination address IP Mo,3 traversing router 1402E. The combination of dynamic source addressing and multiroute data transport is 16 illustrated in FIG. 45, where SDNP client 1400 communicates with multiple gateways 17 1401A, 1401B, and 1401C using dynamic source addresses. In this method, first data 18 packet 1405A comprises payload SDNP 1 with dynamic IP source address Ci, and 19 destination address Mo,o. Data packet 1405A is then routed over Last Link 1404A through routers 1402A and 1402B to SDNP gateway 1401A. In a similar manner a second data 21 packet 1405B comprises payload SDNP 2 with dynamic IP source address C1,2 and 22 destination address Mo,. Data packet 1405B is then routed over Last Link 1404B through 23 router 1402C to SDNP gateway 1401B. A third data packet 1405C comprises payload 24 SDNP 3 with dynamic IP source address C1,3 and destination address Mo,3. Data packet 1405C is then routed over Last Link 1404C through routers 1402D and 1402E to SDNP 26 gateway 1401C. 27 As such, each successive data packet contains changing SDNP payloads, employs 28 dynamically changing source addresses, routed through different Last Links to unique 29 SDNP gateways. In order to transport data over multiple Last Links, namely Last Links 1404A, 1404B, and 1404C, either a single router with multiple IP inputs such as a 31 DOCSIS3 cable modem with trellis encoding, or over multiple forms of media, e.g.

1 multiple bands of WiFi, combinations of radio and WiFi, or other combinations of 2 wireline and wireless communication are used. In one example, FIG. 46A depicts an IP 3 stack of multi-route last mile HyperSecure communication using dynamic client IP 4 addresses over a single PHY last link 1404. Client device 1400, illustrates a shared physical interface comprising Layer 1 and Layer 2 communication shown in IP stack 6 1411A. On network Layer 3, IP stack 1411A generates client address Ci,directed to 7 SDMP gateway Mo,o, IP stack 141lB generates client address C1,2 directed to SDMP 8 gateway Mo,, and IP stack 141IC generates client address C1,3 directed to SDMP 9 gateway Mo,3. The same multi-route approach can be combined with dynamic client addressing 11 and multiple PHY last layers as shown in the IP stack depiction of FIG. 46B. As shown, 12 client device 1400 contains three IP stacks 1411A, 1411B, and 1411C transporting IP 13 datagrams with corresponding IP addresses IP C1,1, IP C1,2, and IP C1,3 over 14 corresponding Last Links 1404A, 1404B, and 1404C to SDNP gateway having IP addresses IP Mo,o, IP Mo,, and IP Mo,3. 16 In many cases, the Last Link comprises a single route, where beyond the first 17 router multiroute data transport is employed. In FIG. 47, SDNP client 1400 18 communicates with a single router 1402A over Last Link 1404. Beyond router 1402A, 19 the data packets are directed to multiple gateways 1401A, 1401B, and 1401C using dynamic source addresses. In this implementation, first data packet 1405A comprises 21 payload SDNP 1 with dynamic IP source address C, and destination address Mo,o. Data 22 packet 1405A is routed over Last Link 1404 and through routers 1402A and 1402B to 23 SDNP gateway 1401A. 24 In a similar manner, a second data packet 1405B comprises payload SDNP 2 with dynamic IP source address C1,2 and destination address Mo,. Data packet 1405B is routed 26 over Last Link 1404 and through routers 1402A and 1402C to SDNP gateway 1401B. A 27 third data packet 1405C comprises payload SDNP 3 with dynamic IP source address C1,3 28 and destination address Mo,3. Data packet 1405C is successively routed over Last Link 29 1401 and through routers 1402A, 1402D and 1402E to SDNP gateway 1401C. As such, each successive data packet contains changing SDNP payloads, employs dynamically

1 changing source addresses, routed through a common Last Links to unique SDNP 2 gateways. 3 This Last Mile connection is illustrated using IP stacks in FIG. 48 where IP stack 4 1411 in SDNP client device 1400 with a Last Link 1404 exclusively with router 1402A sends data packets on network Layer 3 to stack 1412A comprising three different 6 network addresses, specifically P C1,1, IP C1,2, and TP C1,3. As such client device 1400 7 appears to router 1402A as three separate clients even though it actually comprises a 8 single client. Once the TP datagrams reach router 1402A, they split and take different 9 routes to different destination gateways. Packets with source address IP Ci, may for example, be routed through router 1402B to destination IP Mo,o, packets with source 11 address P C1,2, may routed through router 1402C to destination IP Mo,, and packets with 12 source address IP C1,3, may be routed through routers 1402D and 1402E to destination IP 13 M,3. The routing table for directing a data packet with a given dynamic client address 14 Cinto a specific SDNP gateway is not pre-fixed and can be varied dynamically. P addresses can be assigned on a packet-by-packet basis, further obfuscating the fact that 16 the apparently unrelated data packets are all part of a single fragmented communication 17 between two callers. 18 Physical Realization ofLast Mile Routing - Physical realization of the Last Mile 19 may comprise communication over a variety of media, including Ethernet, WiFi, cellular, or DOCSIS3 enabled cable and fiber links. Regardless of the medium used, routing of 21 data packets over the Last Mile is primarily controlled by three variables, namely, 22 • The media access control (MAC) addresses of communicating 23 devices, 24 • The source IP address of the IP datagram, • The destination IP address of the IP datagram. 26 As such, MAC addresses control the physical media used to perform each hop in 27 the Last Mile communication, i.e. Layer 1 and Layer 2 information, while the IP 28 addresses identity the client device and the SDNP gateway, i.e. the devices at the two 29 ends of the Last Mile. Although the payload used in HyperSecure communication follows the protocols defined in accordance with the secure dynamic communication network and 31 protocol, intermediate devices in the Last Mile, i.e., routers and other devices on the route

1 of a packet between the client device and the gateway, are generally not enabled to 2 execute SDNP functions because of the lack of SDNP executable code in such devices. 3 Therefore, the SDNP payload has no bearing on the routing of Last Mile HyperSecure 4 data packets. One example is the use of Ethernet for Last Mile communication. Adapting the 6 Ethernet data packet described previously in FIG. 9E for SDNP Last Mile 7 communications, FIG. 49 is a graphical representation of IPv4 and IPv6 datagrams for 8 Ethernet communication carrying a SDNP payload. As shown, Layer 1 Ethernet packet 9 188 comprises data frame header, i.e. preamble 180, start frame delimiter SFD 181, and Layer 2 Ethernet packet 189. Ethernet packet 189 includes destination and source MAC 11 addresses 182 and 183, an optional 802.1Q tag 184 for VLAN implementation, Ethertype 12 field 185 used to specify the type of data link employed (either Ethernet II or the length 13 specification according to IEEE802.3), and frame check 186 comprising a 32-bit CRC 14 checksum of the entire data link packet. Ethernet packet 189 also contains variable length MAC payload 187 used to encapsulate the IP datagram's SDNP content 1430. 16 Specifically, MAC payload 187 contains an IP header 434 and an IP payload 435 17 comprising transport-header 436 and SDNP payload 1430. 18 IP header 434 varies depending on whether the IP datagram follows the IPv4 or 19 IPv6 protocol as determined by protocol field 447 comprising binary 4 or protocol field 448 comprising binary 6. Preambles 440 and 444 both contain a transport header flag 470 21 used to determine the Layer 4 transport method employed, e.g. TCP, UDP or the 22 maintenance functions ICMP and IGMP. Specifically, in accordance with the secure 23 dynamic communication network and protocol, TCP transport is employed for software 24 and data files, while UDP is employed for real time data such as VoIP and video. The length and format of the transport header 436 varies in accordance with transport header 26 470. IP header 434 contains IPv4 source and destination addresses 441 and 442 or Pv6 27 source and destination addresses 445 and 446. 28 Last Mile routing of Ethernet packets depends both on the IP addresses and the 29 MAC addresses, represented by exemplary names of the devices to which the IP or MAC address refer to, e.g. MAC Ci, or IP Mo,o. The symbolic names, representing a numeric 31 address made in accordance with the Ethernet formatted Internet protocol, are used in lieu

1 of numerical addresses for the sake of clarity. Note that IP address IP Ci, follows 2 different formats and employs a different number of bytes for IPv4 and IPv6 names. 3 Moreover the format for the MAC address varies with the Layer 2 data link protocol 4 employed. As such, the MAC address MAC Ci, for cellular radio is not the same as the MAC address for the same device communicating using WiFi or Ethernet. MAC 6 addresses have no relationship to IP addresses, i.e. the IP address and MAC address for 7 the same client have no relationship. 8 Sequential Last Mile routing of Ethernet packets is shown in the examples of 9 FIG. 50A through FIG. 50D. Each illustration contains two Ethernet packets - a top one comprising an IPv4 datagram and a lower one comprising an IPv6 datagram. Because 11 IPv4 and IPv6 use different formats with varying field lengths, the two Ethernet packets 12 shown are generally not of the same length even when carrying identical payloads. In the 13 first step of the communication sequence, SDNP payload-A travels from SDNP client 14 1400 to router 1402A over Last Link 1404 and then across gateway link 1414 to the SDNP gateway 1401. A response from the SDNP gateway to the client involves SDNP 16 payload G traveling from SDNP gateway 1401 over gateway link 1414 to router 1402A, 17 then across Last Link 1404 to client 1400. SDNP client 1400 has numeric MAC and IP 18 addresses MAC Ci, and IP Ci,, router 1402A has numeric MAC address MAC R, and 19 SDNP gateway has numeric MAC and IP addresses MAC Mo,o and IP Mo,o. The IP address of router 1402A is not used in the data packets. 21 Unlike in the SDNP cloud where packet routing of SDNP datagrams is 22 completely controlled by the SDNP network, in Last Mile communication using IP 23 datagrams, the SDNP payload cannot be interpreted or affect routing, meaning each 24 communication transported across the Last Mile contains fixed source and destination IP addresses. The physical media or channels used to direct the Ethernet packets is governed 26 by the MAC addresses connecting each communication node in the Last Mile. For 27 example, FIG. 50A illustrates IPv4 and IPv6 Last Link Ethernet packets used for single 28 PHY routing to router 1402A comprising source MAC address MAC Ci,, destination 29 MAC address MAC R, source IP address IP Ci,, destination address IP Mo,o, and a SDNP payload. FIG. 50B illustrates the corresponding Ethernet packets transporting 31 SDNP payload A over gateway link 1414. As described, the source and destination IP

1 addresses remain unchanged at IP Ci, and IP Mo,o while the MAC source and destination 2 addresses change from their original values to MAC R and MAC Mo,o. 3 In the reply communication from SDNP gateway 1401 to client 1400, SDNP 4 payload G traverses the same network in reverse sequence, i.e. where the source and destination addresses are swapped. As shown in FIG. 50C, the source and destination IP 6 addresses comprise IP Mo,o and IP Ci, respectively while the MAC addresses include 7 source address MAC Mo,o and destination MAC R. In the Last Link communication 8 shown in FIG. 50D, MAC addresses change to source address MAC R and destination 9 MAC Ci, while the source and destination IP addresses remain unchanged to IP Mo,o and IP Ci,. 11 One convenient means to represent Last Mile communication from an SDNP 12 client is by utilizing "abridged" data packets containing data fields containing source and 13 destination MAC addresses, source and destination IP addresses, and the SDNP payload. 14 The abbreviated form is convenient for illustrating data flow in any communication "session", i.e. the constructing of successive data packets transmitted across the Last Mile 16 to the SDNP gateway, and the responses thereto. For example, successive Ethernet 17 packets (shown in abridged form) sent from a SDNP client to the SDNP gateway is 18 illustrated in the top portion of FIG. 51A. Each row represents successive data packets 19 containing SDNP payloads, A, B, and C. The leftmost column illustrates the data packets in the Last Link while the right column illustrates data packets carrying the same 21 payloads over the gateway link. As shown, all packets specify IP Ci, as the source IP 22 address and IP Mo,o as the destination IP address. Since only one pair of IP addresses are 23 employed the Last Mile is referred to herein as a SDNP single route Last Mile 24 communication. Furthermore, since the source IP address used by SDNP client 1400 to transport successive data packets is unchanging, the Last Link employs "static client 26 addressing". 27 To facilitate Layer 2 interconnection among each communication node to its 28 neighbors, the MAC addresses in different segments of the Last Mile necessarily change. 29 As shown, all successive packets traveling across the Last Link from the client to the router employ source and destination MAC addresses MAC Ci, and MAC R. Since a 31 single MAC address is used for the client in successive data packets, the Last Link

1 comprises a single physical medium, i.e. a single-PHY Last Link. Transport over the 2 gateway link employs source and destination MAC addresses MAC R and MAC Mo,o 3 respectively. 4 So although the data packet shown encloses a SDNP payload, routing over the Last Mile necessarily uses sniffable MAC and IP addresses - addresses that can be 6 interpreted by monitored by unauthorized listeners. By tracking packets with identical 7 source and destination IP addresses an unauthorized listener can deduce that the data 8 packets are likely part of the same conversation or session and even though they cannot 9 open the SDNP payload, they can still gather metadata such as call times, files sizes, data rates, etc. to develop a profile of the caller. Moreover, by following the MAC and IP 11 addresses, metaphorically like a trail of breadcrumbs, a hacker can potentially trace a 12 call's origin to the end device, i.e. the client device, and thereafter personally identify the 13 caller. 14 As disclosed herein, a superior way to prevent client device tracing, obfuscate related call packets, and inhibit the gathering of metadata is to dynamically change MAC 16 and IP addresses in Last Mile and Last Link communication. These inventive methods of 17 deception include: 18 • Sending data packets over changing communication mediums by 19 dynamically changing the Last Link MAC addresses, referred to herein as "multi PHY Last Link" communication, 21 • Disguising the caller by dynamically changing the identity of the 22 client device's IP address, referred to as "dynamic client addressing", 23 • Changing the communication path of successive data packets over 24 the Last Mile by dynamically changing the IP address of communication to and from different SDNP gateway IP addresses, referred to herein as "multi-route Last 26 Mile" communication. 27 The combination of multi-PHY, dynamic client addressing, and multi-route Last 28 Mile communication renders tracking and tracing of Last Mile and Last Link 29 Communication extremely challenging because only the SDNP caller and the SDNP gateway know which packets are part of the same call or session. These methods can be 31 used separately or in combination.

1 For example, the lower half of FIG. 51A illustrates the use of multi-PHY Last 2 Link communication in a single route Last Mile communication with static client 3 addressing. As shown, each row comprises a pair of data packets using in a 4 communication from an SDNP client to the SDNP gateway - the left side representing the Last Link data packet, the right side describing the gateway link data package. The 6 three rows represent three successive messages, the top row containing the first data set 7 "SDNP payload A", the middle row containing SDNP payload B, and the bottom row 8 describing the third successive data packet containing SDNP payload C. For single route 9 Last Mile communication with static client addressing all successive data packets use a static client address IP Ci and fixed destination IP address IP Mo,o. 11 In order to execute multi-PHY Last Link communication, i.e. to route data in the 12 Last Link over multiple physical mediums, the MAC address of the SDNP client must be 13 dynamically changed in sequential data packets. Each MAC address corresponds to a 14 specific PHY layer, e.g. Ethernet 100BASE-T and 1000BASE-T connections. In the case of three physical mediums, the client's MAC address is dynamically changed 16 successively packets from MAC Ci, to MAC C1,2, then to MAC C1,3. If only two 17 mediums are available, the MAC addresses can be varied in a random pattern to avoid 18 pattern recognition, such as MAC Ci,, MAC C1,2, MAC C1,2, MAC Ci,, MAC C1,2,

19 MAC Ci,, MAC C1,2, MAC Ci,, . . While the source MAC address is varied, the MAC destination for the Last Link may remains constant, i.e. as MAC R. Since all of the Last 21 Link's multi-PHY paths terminate in the same router, the data path through the remainder 22 of the Last Mile remains fixed as a single route communication. In other words, even 23 though the Last Link utilizes a multi-PHY connection, the Last Mile enters the SDNP 24 cloud through a single gateway and the Last Mile comprises single-route communication. Although the multi-PHY approach provides a degree of deception, packet sniffing 26 data packets from the specific call can still be identified because they share a common 27 client IP address. This method of detection is thwarted using dynamic client addressing 28 an operation where the client changes its IP address with each packet it sends. As an 29 example, FIG. 51B illustrates the use of client dynamic IP addressing in single route Last Mile communication. The top set of data packets illustrate a single PHY Last Link 31 connection while the lower set of data packets describe a multi-PHY implementation. In

1 SDNP single route Last Mile communication, the destination IP address 442 of the SDNP 2 gateway remains fixed with a numeric value IP Mo,o in all data packets regardless of 3 whether single PHY or multi-PHY methods are used. 4 As shown, in dynamic client addressing data packets carrying SDNP payload A employ a dynamically selected source IP address 441 comprising IP Ci,, while data 6 packets carrying SDNP payload B employ a dynamically selected source IP address 7 comprising IP C1,2, data packets carrying SDNP payload C use a dynamically selected 8 source IP address comprising IP C1,3 and so on. The number of dynamically selected 9 addresses is nearly unlimited, especially in IPv6. Moreover, IP addresses may be reused so long that some time, e.g. 1 second, transpires before the address is recycled. In the 11 case of dynamic client addresses with a single-PHY Last Link, the value of the source 12 MAC address 183 remains constant, in this example at MAC Ci, even though the IP 13 source address changes. In the case of dynamic client addresses with a multi-PHY Last 14 Link, the value of the source MAC address 183 varies successively, changing from MAC Ci, to MAC C1,2 and then to MAC C1,3. There is no particular mathematical 16 correspondence between the client's changing MAC address and its dynamic IP address. 17 Although dynamic client addressing appears to comprise messages sent from 18 different users, the data packets still traverse most of the Last Mile (other than the Last 19 Link in multi-PHY implementations) over a single route. A more advanced method to confound packing sniffing of Last Mile communication is to employ "multi-route" 21 communication. In multi-route communication more than one SDNP gateway IP address 22 is employed to connect the client to the SDNP cloud. Because SDNP network routing is 23 prescribed by signaling servers and uses identifying SDNP tags on each packet, the 24 SDNP cloud is able to route packets to a destination regardless of whether the data enters the SDNP cloud through a single gateway or through multiple gateways. FIG. 51C 26 illustrates the use of multi-route Last Mile communication with static client addressing. 27 In every data packet shown in the last link, the client's source IP address 441 remains 28 static with a numeric value IP Ci, while successive data packets containing SDNP 29 payloads A, B, and C dynamically vary the destination IP address 442 from IP Mo,o, to IP Mo, to IP Mo,3. The IP addresses of the SDNP gateways are not randomly selected, but 31 "chosen" by the SDNP signaling servers to represent gateways temporally close to the

1 caller, i.e. those gateways with a minimal statistical propagation delay between the SDNP 2 client and the specific SDNP gateway. In this example, the dynamic destination addresses 3 change irrespective of the PHY connections. For example, the top set of data packets 4 illustrate a single PHY Last Link connection with a client source MAC address 183 for the Last Link having a numeric value MAC Ci, while the lower set of data packets 6 describe a multi-PHY implementation varying the MAC source address across different 7 mediums, e.g. MAC Ci,, MAC C1,2, and MAC C1,3. There is no corresponding pattern or 8 mathematical relationship between the changing MAC addresses of the client and the 9 destination IP addresses of the SDNP gateways. The most effective degree of deception is to combine dynamic client addressing 11 with multi-route Last Mile communication. This novel combination of security features is 12 shown in FIG. 51D both for single-PHY Last Link implementation (shown in the top half 13 of the illustration), and for a multi-PHY Last Link version shown in the lower half In this 14 fully dynamic version shown in the lower half, the source IP address 441 dynamically and randomly changes from IP C1,1, to IP C1,2, and to IP C1,3 while independently the 16 destination IP address 442 of the SDNP gateway changes from IP Mo,o, to IP Mo, to IP 17 M,3. The SDNP gateway address is selected by the SDNP signaling servers to minimize 18 propagation delay while the dynamic client address changes in an unrelated manner. As 19 in the previous examples, the top set of data packets illustrate a single PHY Last Link connection with a client source MAC address 183 for the Last Link having a numeric 21 value MAC Ci, while the lower set of data packets describe a multi-PHY 22 implementation varying the MAC source address across different mediums, e.g. MAC 23 Ci,, MAC C1,2, and MAC C1,3. There is no corresponding pattern or mathematical 24 relationship between the changing MAC addresses of the client and the changing IP addresses of the client or SDNP gateway. However, in multi-route Last Mile 26 communication, a multi-PHY Last Link may advantageously connect to three distinct 27 routers Ri, R2, and R3 rather than funnel all the data into a single router R. 28 Last Mile deception as described previously represents ten different cases as 29 summarized in the table of FIG. 52A, ranging from the least secure implementation (shown at the bottom of table as row # 10) comprising a single route Last Mile with a 31 static client address and a single-PHY Last Link to the superior deception offered by a

1 multi-PHY Last Link with dynamic source addressing and multi-route Last Mile 2 communication at the top row # 1. The intermediate combinations are ranked in order of 3 security. The notations Cin, Mo,n, and Ra refer to dynamically changing addresses for 4 SDNP clients, SDNP gateways, and the Last Link router. The dynamic addresses are uncorrelated. Rows 7 to 10 describe single route Last Mile communication, i.e. 6 employing a single gateway Mo,o, while rows 1 to 6 describe multi-route Last Mile 7 communication with multiple gateways. Except for shaded rows 1 and 4, Last Link 8 communication connects to a single router with MAC address R. In contrast, in multi 9 route communication, shaded rows 1 and 4 describe multi-PHY Last Link communication to multiple routers with dynamic MAC addresses Ra. 11 The operation of the single-route Last Mile communication is shown 12 topologically in FIG. 52B in four combinations - static client addressing with single 13 PHY Last Link, static-client addressing with multi-PHY Last Link, dynamic client 14 addressing with single-PHY Last Link, and dynamic client addressing with multi-PHY Last Link. Each box illustrates three successive data packet communications showing the 16 data path employed. Solid lines represent data packet flow while dotted lines illustrate 17 possible paths not being utilized. Shaded circles illustrate communication nodes 18 employed in the Last Mile communication, while empty circles illustrate unused 19 communication nodes. As shown, all examples terminate the Last Mile data routing through a single connection between router R and SDNP gateway Mo,o. 21 In the case of the static client addressing over a single-PHY Last link shown in 22 the upper left corner, each successive packet takes the same path over the entire Last Mile 23 using unchanging IP addresses. In the case of the static client addressing over a multi 24 PHY Last link shown in the lower left corner, each successive packet takes a different path over the Last Link as prescribed by dynamically changing MAC addresses. The 26 remainder of the Last Mile comprises a single route as specified by unchanging IP 27 addresses. Despite the single route transport, changing the physical media of the Last 28 Link makes caller tracing more difficult. In the case of the dynamic client addressing 29 over a single-PHY Last link, shown in the upper right corner, each successive packet takes the same path over the entire Last Mile using an unchanging destination IP address 31 and a constant client MAC address for the Last Link. Deception is instead achieved by

1 changing the identity of the client by means of changes in the dynamic source IP address. 2 In the case of single route communication with both dynamic client addressing and a 3 multi-PHY Last Link, shown in the lower right corner, the client's MAC address and 4 source IP address change dynamically and randomly even though all packets are routed to a single SDNP gateway. 6 Dynamic client addressing is the process whereby a client device employs one or 7 more temporary adhoc IP addresses. The process involves two stages. In the first stage, 8 when a device first logs on to a network it registers its presence on the local subnet by 9 contacting the nearest router. The router then redirects the connection to the nearest DHCP server on the same subnet. DHCP, an acronym for dynamic host configuration 11 protocol (DHCP) is a network management protocol used to dynamically assign IP 12 addresses. In the registration process, the client device downloads one or more IP 13 addresses and stores the addresses in its communication data register. Until such time that 14 the assigned IP addresses are renewed by the local DHCP server, either by starting a new session or requesting new addresses, whenever the client device communicates it uses 16 these IP addresses. Because the addresses are dynamically issued within a specific 17 subnet, the client device's IP addresses are not Internet addresses. 18 In the second stage when the client device either places a call or logs onto the 19 SDNP network, the device automatically contacts the SDNP signaling server based on a static IP address of the SDNP server. The SDNP server upon receiving the incoming 21 message uploads the ad hoc IP address or addresses to the SDNP name server. The SDNP 22 name server then assigns SDNP addresses as pseudo-code for each of the temporary IP 23 addresses. In operation, just before routing the packet's SDNP source address is 24 substituted by its local ad hoc IP address. In the case of SDNP dynamic addressing, the identity of the client device is camouflaged, by repeatedly sending packets with changing 26 source addresses. In this manner, dynamic deception obscures the true identity of the 27 client device. 28 Upon reaching a SDNP gateway, the source addresses for outgoing packets 29 discard the client IP addresses and substitute the SDNP address of the gateway server instead. Each outgoing SDNP packet then swaps the local IP address of the device with 31 its local adhoc IP address just prior to transport. Unlike Internet packet transport where

1 the source and destination IP addresses remain constant and are required for replies, in 2 SDNP transport each hop uses new IP addresses. So when a SDNP message finally 3 reaches its destination, the source address of the client device is not included in the data 4 packet. Instead the signaling server informs the destination device about the return path for replies. 6 The operation of "multi-route" Last Mile communication is shown topologically 7 in FIG. 52C in four combinations of static and dynamic client addressing as well as 8 single-PHY and multi-PHY last links. In each multi-route communication, the destination 9 IP address, i.e. the SDNP gateway, constantly changes, meaning that the Last Mile route connects to different inputs to the SDNP cloud. In the left column the client addresses 11 remain static, meaning the identity of the caller is unchanged. The upper left corner 12 example uses a single-PHY connection for the Last Link, meaning the MAC address for 13 the client also remains static. Even though the communication occurs to different 14 destination gateways, the unchanging Last Link physical medium and unchanging client IP address makes the Last Mile susceptible to call tracing. This weakness can be 16 remedied either by changing the Last Link medium used to transport the data packets or 17 by disguising the true identity of the caller's IP address. 18 The lower left corner example uses a multi-PHY connection for the Last Link, 19 meaning the MAC address for the client changes dynamically. Such an approach compensates for the fact that the identity of the client maintains a static IP address. As 21 part of end-to-end multi-route Last Mile communication, each unique Last Link connects 22 to separate routers on successive packets' journeys to distinct SDNP gateways. As such, a 23 first packet is routed from a client with static address IP Ci, to the router with MAC 24 address MAC Ri over a unique PHY medium before finally being routed to SDNP gateway with IP address IP Moo. A second packet the identical client address IP Ci, is 26 routed to a different router with media address MAC R2over a unique PHY medium 27 before finally being routed to SDNP gateway with IP address IP Mo,. Similarly a third 28 packet also with static client IP address Ci, is routed to a router with a media address 29 MAC R3over a unique PHY medium where it is subsequently routed to SDNP gateway Mo,3. The use of multiple routers opportunistically uses the multiple PHY Last Link to

1 deliver Last Mile packet in entirely separate trajectories despite utilizing a client with a 2 singular source IP address. 3 In another embodiment shown in the upper right corner, the identity of the client 4 changes dynamically even though only a single MAC address and PHY connection is used. The IP address of the client shown dynamically changes from IP Ci, to IP C1,2 to IP 6 C1,3 while the physical medium remains constant with a source media address MAC Ci 7 and a destination address MAC R. The data is then routed onward to gateways Mo,o, Mo,, 8 and Mo,3 in random order as determined by the SDNP signaling servers. 9 Superior security is achieved by combining all three methods of Last Mile deception, namely multiple route communication using a multi-PHY Last Link and 11 dynamic client addressing. This case is illustrated in the lower right hand corner of FIG. 12 52C where data packets sent using a multi-PHY Last Link and multiple routers are 13 delivered from a client with dynamic IP addresses to multiple SDNP gateways over 14 multiple routes. As shown, a first packet from a client with dynamic source network address IP Ci, is sent over multiple routes to a destination IP Mo,o using a multi-PHY 16 Last Link defined by source and destination media addresses MAC Ci, and MAC Ri. A 17 second data packet from a client having a dynamically selected source network address 18 IP C1,2 is sent over multiple routes to a destination IP Mo, using a multi-PHY Last Link 19 defined by source and destination media addresses MAC C1,2 and MAC R2. Lastly a third data packet from a client having a dynamically selected source network address IP C1,3 is 21 sent over multiple routes to a destination IP Mo,3 using a multi-PHY Last Link defined by 22 source and destination media addresses MAC C1,3 and MAC R3. In this way the 23 combination of Client IP address, SDNP gateway IP address, the client's MAC address 24 and the router's MAC address all change dynamically in random fashion, rendering call tracing and the collection of meta data nearly impossible. 26 Camouflaging of the client device IP address and obfuscation of last mile routing 27 by dynamic IP addressing, multi-PHY transport and multi-route transport to multiple 28 gateways can be determined either by the client device or by the signaling server. The 29 misdirection process can be achieved using random number generation or other pseudo random algorithms. A key principle is that the routing and transport changes are 31 unpredictable.

1 Two slightly less robust versions of Last Mile data transport of Ethernet packets 2 over multiple routes are shown in FIG. 52D where the left side illustration employs static 3 client addressing and multi-PHY Last Link connectivity while the right side graphics 4 represents dynamic client addressing, also with multi-PHY Last Link connectivity. The difference between these implementations and the multi-PHY versions shown in FIG. 6 52C previously is that these versions employ a single router R rather than spreading data 7 transport across multiple routers. In short, in multi-route transport using a single router 8 for Last Link connectivity, sequential data from the client is spread across multiple 9 physical mediums, i.e. a multi-PHY Last Link, then re-collected by a single router R and sent over the remainder of the Last Mile including multiple gateway links and any other 11 parallel sections of the Last Mile (not shown) from this common router to multiple SDNP 12 gateways defined by distinct destination IP addresses. 13 As an adjunct to Ethernet, WiFi wireless communication also can be employed 14 for Last Mile communication between a SDNP client and a SDNP gateway. WiFi communication requires a data packet with three or four MAC addresses, two for the 16 radio link, one or two for the wired network connection, specifically using Ethernet data 17 packets. FIG. 53 illustrates the same WiFi packet format adapted for SDNP Last Mile 18 and Last Link communication. As an access point applicable for Last Link 19 communication, only three 6B-long MAC addresses are required, specifically MAC address 1 field 235 for the receiving radio base station or "receiver", MAC address 2 field 21 236 for the transmitting radio base station or "xmitter", and MAC address 3 field 237 22 comprising the MAC address of the wired network connection to the WiFi router, i.e. 23 Ethernet or "net". In operation, the numerical values of the MAC addresses loaded into 24 the receiver and xmitter data fields depend on the To DS / From DS directional setting to determine (i) is the data packet being received on the radio and forwarded onto Ethernet 26 or (ii) is incoming data on Ethernet being converted into radio communication. MAC 27 address 4 data field 239 is optional, used only when the WiFi device is being employed 28 as a radio bridge in "wireless distribution mode". While such a mode may be used in Last 29 Mile communication over long distances as an alternative to cellular or microwave networks, e.g. in the desert, in general the use of a WiFi communication in SDNP Last 31 Mile is generally focused on the Last Link connection to the SDNP client. As such, the

1 following discussion will focus on the access point mode for WiFi routers with the 2 understanding that the SDNP techniques herein are equally applicable in wireless 3 distribution mode routing. 4 Similar to Ethernet data packets, preamble 230 and start frame delimiter SFD 232 contain Layer 1 data for synchronizing the data and device. Physical layer convergence 6 procedure PLCP 232 comprises a mix of Layer 1 and Layer 2 information (related packet 7 length, data rates, error checking on the header, etc.). In accordance with IEEE 802.11 8 standards, the remaining data fields comprise Layer 2 data link information including 9 Frame Control 233 specifying the WiFi version packet type as management, control, reserved, or "data", the type used in delivering SDNP payloads. 11 Duration & ID 234 contains the NAV duration unless the WiFi device is in power 12 savings mode, in which case the field includes the station ID. NAV or network allocation 13 vector is a virtual carrier-sensing mechanism used for power saving in wireless 14 communication systems. The NAV duration can be considered as a counter, counting down to zero at a uniform rate, whereupon it senses the medium to determine if the radio 16 is idle or still communicating. In idle mode, the counter counts the NAV duration 17 repeatedly, checking to determine if any radio communication activity demanding 18 attention is detected. Sequence control or "Sequence" field 238 describes the packet 19 sequence and fragment number defining the Layer 2 packet frame. Frame check 240 contains a 32-bit CRC checksum of the entire data packet, i.e. a error check data link 21 trailer. 22 WiFi payload 241 is a OB to 2,312B long data field used to carry the WiFi 23 payload. In SDNP Last Mile communication, this field contains the IP datagram used in 24 Last Mile communication including IP header 434, transport-header 436 and SDNP payload 435 26 IP header 434 varies depending on whether the IP datagram follows the IPv4 or 27 IPv6 protocol as determined by protocol field 447 comprising binary 4 or protocol field 28 448 comprising binary 6. Preambles 440 and 444 both contain a transport header flag 470 29 used to determine the Layer 4 transport method employed, e.g. TCP, UDP or the maintenance functions ICMP and IGMP. Specifically, in accordance with the secure 31 dynamic communication network and protocol, TCP transport is employed for software

1 and data files, while UDP is employed for real time data such as VoIP and video. The 2 length and format of the transport header 436 varies in accordance with transport header 3 flag 470. IP header 434 contains IPv4 source and destination addresses 441 and 442 or 4 IPv6 source and destination addresses 445 and 446. Similar to Ethernet data packets, Last Mile routing of WiFi packets depends both 6 on the IP addresses and the MAC addresses, represented symbolically by the names of 7 the devices to which the IP or MAC address refer to. Sequential Last Mile routing of 8 WiFi packets is shown in the examples of FIG. 54A through FIG. 54D. Each illustration 9 contains two WiFi packets - a top one comprising an IPv4 datagram and a lower one comprising an IPv4 datagram. Because IPv4 and IPv6 use different formats with varying 11 field lengths, the two WiFi packets shown are generally not of the same length even when 12 carrying identical payloads. 13 In the first step of the communication sequence, SDNP payload-A travels from 14 SDNP client 1400 to WiFi base station / router 1402W over Last Link 1404 as WiFi radio medium, and by wireline onto router 1402X over BS link 1415. Router 1402X then 16 delivers the data packet across gateway link 1414 to the SDNP gateway 1401. A response 17 from the SDNP gateway to the client involves SDNP payload G traveling from SDNP 18 gateway 1401 by wireline over gateway link 1414 to router 1402X, across BL link 1415 19 to WiFi router 1402W, and across Last Link 1404 to client 1400 using WiFi radio as the communication medium. SDNP client has numeric MAC and IP addresses MAC Ci, and 21 IP Ci,, WiFi router 1402W has numeric MAC address MAC W, router 1402A has 22 numeric MAC addresses MAC R, and SDNP gateway has numeric MAC and IP 23 addresses MAC Mo,o and IP Mo,o. The IP addresses of WiFi router 1402W and wireline 24 router 1402X are not required in the Last Mile communication shown. In contrast to the SDNP cloud, where packet routing of SDNP datagrams is 26 completely controlled by the SDNP network, in Last Mile communication using IP 27 datagrams, the SDNP payload cannot be interpreted or affect routing, meaning each 28 communication transported across the Last Mile contains fixed source and destination IP 29 addresses. The physical media or channels used to direct WiFi packets in radio communication and to direct Ethernet packets in wireline communication is governed by 31 the MAC addresses connecting each communication node in the Last Mile.

1 For example, FIG. 54A illustrates IPv4 and IPv6 Last Link WiFi packets used for 2 single-PHY radio routing to WiFi router 1402W over Last Link 1404, comprising xmitter 3 MAC address MAC Ci, and receiver MAC address MAC W. WiFi router 1402W also 4 provides BS link wireline 1415 routing to Ethernet router 1402X with a "net" MAC destination address MAC R. Layer 3 network routing comprises only the end devices, i.e. 6 SDNP client 1400 having source IP address IP Ci,, and SDNP gateway 1401 having 7 destination address IP Mo,o. Unlike an Ethernet data packet, a WiFi packet contains three 8 addresses - a xmitter or source-radio MAC address MAC Ci, a receiver or radio 9 destination MAC address MAC W, and an Ethernet "net" address MAC R. In this direction of data transmission, the wireline router 1402X acts as the network destination 11 of the WiFi router device. As such, the WiFi data packet specifies two mediums, WiFi 12 radio Last Link 1404, and Ethernet wireline BS link 1415. FIG. 54B illustrates the 13 corresponding Ethernet packets transporting SDNP payload A over gateway link 1414. 14 As described, the source and destination IP addresses remain unchanged as IP Ci, and IP Mo,owhile the MAC source and destination addresses change from their original values 16 to MAC R and MAC Mo,o. 17 Reply communication involves swapping destination and source IP addresses and 18 adjusting the MAC addresses accordingly. FIG. 54C illustrates IPv4 and IPv6 Ethernet 19 packets for data transport from SDNP gateway 1401 to wireline based router 1402X over gateway link 1414. For the Layer 3 datagram information, IP source address 441 contains 21 the network address of the SDNP gateway 1401, i.e. IP Mo,o and IP destination address 22 contains the value IP Ci,, the client's address. The MAC addresses for the gateway link 23 Ethernet packet are MAC Mo,o for the source address 183 and MAC R for the destination 24 MAC address 182. FIG. 54D illustrates IPv4 and IPv6 WiFi packets for wireline BS Link 1415 and 26 WiFi radio based Last Link 1404. Network Layer 3 routing comprises SDNP gateway 27 1401 address IP Mo,o and SDNP client address IP Ci, as source and destination addresses 28 445 and 446. The function of MAC address field 237 labeled "net" changes in 29 accordance with the radio mode. In the transmit mode shown here, this field contains the Ethernet MAC address of the wireline source of the radio's incoming data, i.e. the 31 numerical value MAC R of router 1402X sending data packets to the WiFi access point.

1 In the receiver mode, shown previously in FIG. 54A, this field defines the Ethernet 2 destinationof data received as radio packets and converted into Ethernet packets. In the 3 example shown, "net" field 237 contains the same MAC address of router 1402X, i.e. 4 MAC R, for both transmit and receive modes, meaning the WiFi access point uses a single Ethernet router for Last Mile connectivity. 6 Optionally, in multiroute communication over the Last Mile, the wireline router 7 used for routing data packets received by the WiFi access point, i.e. in receive mode, may 8 be different than the one used for routing data packets to be transmitted by the WiFi 9 access point, i.e. in transmit mode. For example, the network MAC address 237 for radio packets in receiver mode may have a numeric MAC address MAC Ri while in transmit 11 mode, the data may be changed to a different router connection MAC R2, meaning the BS 12 link may optionally comprise a directionally dependent multi-PHY implementation. In 13 transmit mode, Last Link WiFi packets used for single-PHY radio 1404 Last Link routing 14 from WiFi router 1402W to SDNP client 1400 contain xmitter MAC address 236 with a numeric value MAC W and receiver MAC address 235 containing numeric value MAC 16 Ci,. In this direction of data transmission, the wireline router 1402A acts as the source of 17 data to be transmitted by the WiFi router device. As such, the WiFi data packet species 18 two mediums, WiFi radio Last Link 1404, and Ethernet wireline BS link 1415. 19 Cellular networks represent another form of wireless communication adaptable for SDNP Last Mile communication. Cellular networks re-partition incoming Ethernet 21 packets into radio-specific media access control (MAC) packets. Data may be transmitted 22 and received by multiplexing time (TDMA) in, by code division (CDMA), or by 23 spreading the content across multiple sub-channel frequencies (OFDM). In the case of 24 4G/LTE communication based on OFDM or orthogonal frequency division multiplexing, the Layer 2 data packets are stacked across three different levels of embedded service 26 data units or SDUs all within Layer 2; specifically the lowest level comprises the PHY 27 PDU 299 containing the single frame MAC SDU 304 along with MAC header 303 and 28 padding 305 spread across 20 time slots 300 comprising the PHY Layer 1 data. MAC 29 SDU 304 in turn contains radio link control or RLC SDU 308. Radio link control (RLC) is a layer 2 protocol used in 3G (UMTS) and 4G/LTE 31 (OFDM) based telephony. The function of radio link control is to react to upper layer

1 requests in one of three modes, i.e. acknowledged mode, unacknowledged mode, and 2 transparent mode, as well as to provide error detection, error correction, duplicate 3 detection, and packetizing of data in accordance with specified formats. Packetizing of 4 the data includes concatenation, segmentation, and reassembly of RLC SDUs along with reordering and re-segmentation of RLC data PDUs. For example, after allocating time for 6 performing radio overhead functions, single frame RLC SDU 308 is unavoidably limited 7 in the duration and data file size available for carrying a payload. Single frame RLC SDU 8 308 must therefore be split into segments and mapped into a different RLC Layer 2 9 format - multi-frame RLC SDUs 319. As illustrated in FIG. 55, the mapping of single-frame RLC SDU 308 into the 11 various K, K+1, K+2 segments 313, 314, 315, etc. of multi-frame RLC SDUs 319 does 12 not occur on a one-to-one basis. As shown for example, mapping single-frame RLC SDU 13 308 ends in the middle of the K+2 segment 315. The un-transmitted portion of K+1 14 segment remaining is instead transmitted in a new single-frame RLC SDU 312, but only after allowing padding time 310 needed for radio clock synchronization and after 16 processing RLC header 311. In this method, transmission of data encapsulated in the K+2 17 slot resumes precisely where it left off as though the data flow was never interrupted. 18 Operationally, 4G is analogous to pausing the playback of a DVD encoded movie in the 19 middle of a DVD chapter, waiting a moment to perform some other functions, and then resuming playback precisely where it was paused. As such, no data content is lost and the 21 RF data delivery rate of the cellular system is maximized with no wasted radio bandwidth 22 other than packet overhead (such as PDU headers), and minimal data-rate degradation 23 resulting from clock synchronization padding time 310. 24 The multi-frame RLC SDUs 319 encapsulate PDCP PDUs 320 in a one-to-one correspondence with each K segment. For example, the Ktsegment 313 carries PDCP 26 header 321A and an IP payload comprising data 323, the (K+1)hsegment 314 carries 27 PDCP header 321B and an IP payload comprising data 324, the (K+2)thsegment 315 28 carries PDCP header 321C and an IP payload comprising data 325, and so on. The term 29 PDCP is an acronym for Packet Data Convergence Protocol as specified in 3G and 4G/LTE communication protocol, performing functions such as compression, encryption,

1 integrity assurance, as well as user and control data transfer. PDCP headers vary with the 2 type of data being transported, e.g. user data, control data, etc. 3 Since data transport in 4G data packets carry a continuously concatenated stream 4 of data, payload size is not quantized into defined length blocks as they are in Ethernet and WiFi data packets. Instead data fields 323, 324, 325... carried by corresponding 6 Layer 2 data segments 313, 314, 315... can incrementally support any size payload, as 7 shown comprising IP header 434 and IP payload 435 containing transport-header 436 and 8 SDNP payload 1430. Moreover, in OFDM-based communication each time slot 9 concurrently carries data on multiple frequency subcarriers, meaning that the total data throughput is not simply determined by time duration over a single channel as it is in 11 TDMA. For convenience, however, it is often convenient to maintain IP datagram size to 12 match that of Ethernet or WiFi standards. 13 As shown, IP header 434 varies depending on whether the IP datagram follows 14 the IPv4 or IPv6 protocol as determined by protocol field 447 comprising binary 4 or protocol field 448 comprising binary 6. Preambles 440 and 444 both contain a transport 16 header flag 470 used to determine the Layer 4 transport method employed, e.g. TCP, 17 UDP or the maintenance functions ICMP and IGMP. Specifically, in accordance with the 18 secure dynamic communication network and protocol, TCP transport is employed for 19 software and data files, while UDP is employed for real time data such as VoP and video. The length and format of the transport header 436 varies in accordance with 21 transport header bit 470. IP header 434 contains IPv4 source and destination addresses 22 441 and 442 or IPv6 source and destination addresses 445 and 446. 23 As an example of 4G communication using IPv6 datagrams, FIG. 56A illustrates 24 cellular radio 1404 Last Link routing to cell tower and base station 1402Q. Specifically, in MAC source field 300A, the RLC PDU defines cellular source media address as MAC 26 Ci, the client's device. Similarly MAC destination field 300B specifies cellular receiver 27 media address as MAC BS describing the cell tower and base station. Layer 3 network 28 routing comprises only the Last Mile end devices, i.e. SDNP client 1400 having source IP 29 address IP Ci,, shown in source data field and SDNP gateway 1401 having destination address IP Mo,o. As described previously, data fields 323, 324, and 325 do not necessarily 31 correspond to specific sections of the IPv6 datagram data payload, where data field 323

1 includes IP source address 445, IP destination address 446 and a portion of SDNP 2 payload A 435 including transport header 436. Data fields 324 and 325 carry the un 3 transmitted remaining portion of SDNP payload 435. 4 FIG. 56B illustrates the data packets for the reply message SDNP payload G over cellular last link 1404 from cell tower and base station 1402Q to a mobile client device 6 1400 whereby source and destination addresses from the prior data packets have been 7 swapped, namely cellular source media address 300A is loaded with the media address 8 MAC BS, cellular destination media address 300B is set to MAC Ci, the client's MAC 9 address, IP source field 445 in the IPV6 datagram is set to IP Mo,o and IP destination field 445 is set to IP Ci1. Routing between the network router 1402X and cellular tower and 11 base station 1402Q over BS link 1415 uses Ethernet data packets consistent with prior 12 examples. 13 Multi-PHY communication over the Last Link may comprise any of the 14 aforementioned media used in various combinations. Multi-PHY implementations may comprise multiple wireline connections carrying data at the identical or dissimilar data 16 rates and employing common or distinct Layer 2 protocols such as USB, Ethernet 17 1OBASE-T, 100BASE-T, 1000BASE-T, or DOCSIS3. Wireline physical media may 18 comprise Ethernet or USB compliant network cables, coaxial cables, optical fiber, or 19 even twisted-pair copper connections for DSL, albeit at a degraded level of performance. Wireless multi-PHY communication may include combinations of WiFi, cellular, 21 satellite, or proprietary radio formats running in the radio frequency and microwave 22 bands. Wireless Last Link communication may also include short-range technologies 23 such as Bluetooth or micro-cellular networks such as PHS in Japan. Wireless protocols 24 may include cellular formats for 2G, 2.5G, 3G, and 4G/LTE including for example analog, TDMA, GSM, CDMA, UMTS, and OFDM, WiFi protocols such 802.1la, 26 802.1lb, 802.11g, 802.11n, and 802.1lac, as well as proprietary formats for satellite 27 communication or custom radio links. Since Layer 2 protocols vary in accordance with 28 Layer 1 physical mediums, the term multi-PHY communication as used in the context of 29 this disclosure shall mean the combination of both OSI physical and data link layers, i.e. Layer 1 and Layer 2 together, and should not be construed as limiting claims to mean 31 Layer 1 physical media exclusively.

1 Examples of multi-PHY communication using a common Layer 2 protocol are 2 shown in FIG. 57A including Ethernet, WiFi, and cellular implementations. In the 3 topmost example of multi-PHY Ethernet, router 27 communicates to desktop computer 4 36 using two Ethernet cables comprising wired or fiber links 24A and 24B running 100BASE-T and 1000BASE-T respectively. To facilitate HyperSecure communication 6 over the Last Mile, desktop 36 is shown running SDNP software 1335C. 7 In the center example of multi-PHY WiFi, WiFi router 100 communicates to 8 notebook 35 over two WiFi channels shown as WiFi links 29A and 29B, the former 9 running 801.1In protocol over 2.4GHz, and the latter using 802.1lac to communicate over a 5GHz channel. In order to operate in multi-PHY mode, notebook 35 must be 11 enabled to concurrently send and receive signals at multiple frequencies using a multi 12 band antenna 26B internal to the notebook. Similarly WiFi router must be capable of 13 sending and receiving signals at multiple frequencies concurrently using multi-band 14 antennas 26. To facilitate HyperSecure communication over the Last Mile, notebook 35 is shown running SDNP software 1335C. 16 In the lower example showing multi-PHY cellular communication, cellular base 17 station 17 communicates concurrently over multi-band cellular tower 18A to tablet 39 18 using two different radio channels comprising cellular links 28A and 28B with 19 corresponding frequencies 1.8GHz and 900MHz. In the example shown, the cellular link comprises a 4G/LTE network. As shown, tablet 39 must be enabled to concurrently send 21 and receive signals at multiple frequencies using an internal multi-band antenna 18B. To 22 facilitate HyperSecure communication over the Last Mile, tablet 39 is shown running 23 SDNP app 1335A. 24 Such multi-PHY communication using a common Layer 2 protocol confounds cyber attacks because the hacker must gain physical access two different Layer 2 data 26 links each of which may include their own security. Furthermore, provided the client is 27 running SDNP software 1335C, SDNP app 1335A, or SDNP firmware 1335B (not 28 shown), the routing of the SDNP payloads across the multi-PHY connections utilizes 29 unique dynamic security credentials rendering real time SDNP packet interception and interpretation too demanding for real-time hacking.

1 Examples of multi-PHY communication using mixed Layer 1 media and Layer 2 2 protocols are shown in FIG. 57B. In these examples, Last Link data is carried using 3 combinations of cellular, WiFi, and satellite systems. In the top example of mixed 4 medium multi-PHY communication, WiFi router 100 communicates with desktop computer 36 using a combination of 100BASE-T Ethernet wired or fiber link 24B and 6 802.11ac WiFi link 29B operating at 5GHz. To guarantee HyperSecure communication 7 over the Last Mile, desktop 36 is shown running SDNP software 1335C. Such an 8 example represents the combination of wireline and wireless communication, where 9 wireless packet sniffing is unable to intercept or observe the wireline data. This mixed Ethernet + WiFi multi-PHY Last Link distribution method is particularly well-suited for 11 deploying corporate office networks comprising secure desktop computers within a 12 building or campus communicating to private servers locked in access restricted server 13 rooms. 14 In the middle schematic of a mixed-medium multi-PHY communication shown in FIG. 57B, cell phone 32 with internal multi-band antenna 18C communicates using two 16 dissimilar wireless techniques. One PHY connection, WiFi link 29C communicates to 17 WiFi router 100 and antenna 26 using, by example a 802.1In protocol at 5GHz. The 18 second PHY connection, cellular link 28C employs a 1.8GHz carrier running on a 19 4G/LTE protocol to facilitate Last Link connectivity to cellular tower 25 and to base station 17. Since cell cellular tower 25 and WiFi antenna 26 operate on unrelated 21 systems, this multi-PHY approach completely obscures any relationship between the data 22 packets carried by the multiple physical mediums in the Last Link. To guarantee 23 HyperSecure communication over the Last Mile, cell phone 32 is shown running SDNP 24 app 1335A. A similar method to achieve multi-PHY Last Link communication combining 26 cellular and satellite is shown in the bottom illustration of FIG. 57B where satellite /

27 cellular phone 32Z running SDNP app 1335A communicates over two long-distance 28 radio networks - cellular link 28D to cell cellular tower 25 and base station 17 at 1.8GHz, 29 and satellite link 95W to communication satellite 92 at, for example, 1.9GHz. Satellite 92 in turn communicates to terrestrial satellite antenna and base station 92B through wide 31 bandwidth link 95X, not necessarily at the same frequency as client communication.

1 FIG. 57C illustrates another variety of multi-PHY communication - multiple 2 physical mediums sharing common protocols but capable of multiple concurrent 3 communication channels using frequency division. Such a system demands a high 4 bandwidth medium in order to operate without severe loading effects, i.e. where the performance degrades as more users occupy the medium's bandwidth and throughput 6 capability. Only three such mediums are readily available with so much bandwidth, 7 namely (i) DOCSIS3 cable systems using coax cable (ii) DOCSIS 3 cable systems using 8 optical fiber, and (iii) multi-GHz satellite communication systems at low earth orbits. 9 Specifically the topmost illustration of a multi-PHY cable system shows set top box or cable modem 102B running SDNP firmware 1335M communicating to cable CMTS 101 11 using multiple bands over coax or fiber 105 running DOCSIS3 protocol. 12 The bottom illustration represents a multi-PHY satellite network where satellite 13 enabled cellular phone 32Z running SDNP app 1335A communicates to communication 14 satellite 92 using multiple carrier bands 95Z formatted with a proprietary communication protocol. Communication between satellite 92 and terrestrial satellite antenna and base 16 station 92B uses a trunk line protocol 95X mixing thousands of calls, making 17 identification and interception of a specific call problematic for a hacker while use of 18 multi-PHY communication over multiple bands in the client link 95Z insures 19 HyperSecure communication for the client. Another example of the data packets used in multi-PHY Last Link routing is 21 shown in FIG. 58 where SDNP client 1400 communicates with router 1402A over two 22 separate PHY connections comprising Ethernet wired or fiber links 24A and 24B 23 running, for example protocols 100BASE-T and 1000BASE-T respectively. Router 24 1402A in turn connects to SDNP gateway 1401 over gateway link 1414. Both Ethernet packets define the source IP address 445, i.e. the client device, as IP Ci, and the 26 destination IP address 446 of the SDNP gateway as IP Mo,o. Ethernet packet A, routed 27 over a PHY realized by wired or fiber link 24A, includes a MAC destination address 182 28 comprising MAC R and a MAC source address 183 comprising MAC Ci,. Ethernet 29 packet B, routed over a PHY realized by wired or fiber link 24B, includes a MAC destination address 182 comprising MAC R and a different MAC source address 183 31 comprising MAC C1,2 defining the alternate PHY connection.

1 The change in the source media address from MAC Cij to MAC C1,2 redirects 2 Ethernet communication from the 2.6GHz 100BASE-T connection to the 1000BASE-T 3 connection. In operation, data packets from SDNP client device 1400 are fragmented and 4 are then apportioned into SDNP payload A and SDNP payload B in accordance with SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY 6 Last Link occurs with SDNP payload A carried by Ethernet packet A across wired or 7 fiber link 24A and SDNP payload B carried by Ethernet packet B on wired or fiber link 8 24B. 9 Another example of the data packets used in multi-PHY Last Link routing is shown in FIG. 59 where SDNP client 1400 communicates with WiFi router 1402W over 11 two separate PHY connections comprising WiFi links 29A and 29B using, for example, 12 protocols 802.11n at 2.4GHz and 802.1lac at 5GHz, respectively. Router 1402W in turn 13 connects to router 1402X over BS link 1415 and router 1402X connects to SDNP 14 gateway 1401 over gateway link 1414. Both WiFi packets define the source IP address 445, i.e. the client device, as IP Ci and the destination IP address 446 of the SDNP 16 gateway as IP Mo,o. WiFi packet A, routed over a PHY realized by WiFi link 29A, 17 includes xmitter MAC radio source address 236 comprising MAC Ci,, MAC radio 18 receiver destination address 235 comprising MAC W, and MAC network destination 237 19 comprising MAC R. WiFi packet B, routed over PHY realized by WiFi link 29B includes xmitter MAC radio source address 236 comprising MAC C1,2, MAC radio receiver 21 destination address 235 comprising MAC W, and MAC network destination 237 22 comprising MAC R. 23 The change in the source media address from MAC Ci, to MAC C1,2 redirects the 24 transmission from the 2.6GHz WiFi radio to the 5GHz transceiver. In operation, data packets from SDNP client device 1400 are fragmented and then apportioned into SDNP 26 payload A and SDNP payload B in accordance with SDNP algorithms and shared secrets. 27 Fragmented data transport across the multi-PHY Last Link occurs with SDNP payload A 28 carried by WiFi packet A across WiFi link 29A and SDNP payload B carried by WiFi 29 packet B on WiFi link 29B. Yet another example of the data packets used in multi-PHY Last Link routing is 31 shown in FIG. 60 where SDNP client 1400 communicates with cell tower 1402Q over

1 two separate PHY connections comprising cellular links 28A and 28B using, for 2 example, protocols 4G/LTE at 1.8GHz and 4G/LTE at 900MHz, respectively. Router 3 1402Q in turn connects to router 1402X over BS link 1415 and router 1402X connects to 4 SDNP gateway 1401 over gateway link 1414. Both cellular radio packets define the source IP address 445, i.e. the client device, as IP Ci, and the destination IP address 446 6 of the SDNP gateway as IP Mo,o. Cellular packet A routed over PHY realized by cellular 7 link 28A includes xmitter MAC radio source address 300A comprising MAC Ci,, and 8 MAC cell tower destination 300B comprising MAC BS. Cellular packet B routed over 9 PHY realized as cellular link 28B includes xmitter MAC radio source address 300A comprising MAC C1,2, and MAC cell tower destination 300B comprising MAC BS. 11 The change in the source media address from MAC Ci, to MAC C1,2 redirects the 12 transmission from the 1.8GHz 4G/LTE cellular radio to 900MHz. In operation, data 13 packets from SDNP client device 1400 are fragmented then apportioned into SDNP 14 payload A and SDNP payload B in accordance with SDNP algorithms and shared secrets. Fragmented data transport across the multi-PHY Last Link occurs with SDNP payload A 16 carried by cellular packet A across WiFi link 28A and SDNP payload B carried by 17 cellular packet B on WiFi link 28B. 18 As described previously, multi-PHY communication can also comprise dissimilar 19 media. In such cases, the data packet for each connection must be formatted in accordance with the Layer 2 protocols for the corresponding physical media. For 21 example, FIG. 61 illustrates hybrid Last Link communication comprising Ethernet and 22 WiFi where SDNP client 1400 communicates with WiFi router 1402W over two separate 23 PHY connections comprising Ethernet wired or fiber link 24A and WiFi link 29B using, 24 for example, 100BASE-T and 802.11ac at 5GHz, respectively. Router 1402W in turn connects to router 1402X over BS link 1415 and router 1402X connects to SDNP 26 gateway 1401 over gateway link 1414. Both WiFi packets define the source IP address 27 445, i.e. the client device, as IP Ci, and the destination IP address 446 of the SDNP 28 gateway as IP Mo,o. Ethernet A routed over PHY realized by wired or fiber link 24A 29 includes MAC source address 183 comprising MAC Ci,, and MAC destination address 182 comprising MAC W. WiFi packet B routed over PHY realized by WiFi link 29B 31 includes xmitter MAC radio source address 236 comprising MAC C1,2, MAC radio

1 receiver destination address 235 comprising MAC W, and MAC network destination 237 2 comprising MAC R. 3 The change in the source media address from MAC Ci, to MAC C1,2 redirects the 4 transmission from the Ethernet to WiFi. In operation, data packets from SDNP client device 1400 are fragmented then apportioned into SDNP payload A and SDNP payload B 6 in accordance with SDNP algorithms and shared secrets. Fragmented data transport 7 across the multi-PHY Last Link occurs with SDNP payload A carried by Ethernet packet 8 A across wired or fiber link 24A and SDNP payload B carried by WiFi packet B on WiFi 9 link 29B. FIG. 62 illustrates hybrid Last Link communication comprising WiFi and cellular 11 communication where SDNP client 1400 communicates with over two separate PHY 12 connections to two different wireless base stations, specifically WiFi link 29A to WiFi 13 router 1402W operating 802.1In at 2.4GHz and cellular link 28B to cellular base station 14 1402Q operating 4G/LTE over a 900MHz carrier frequency. Routers 1402W and 1402Q in turn connect to router 1402X over BS links 1415A and 1415B, respectively, and router 16 1402X connects to SDNP gateway 1401 over gateway link 1414. Both WiFi and 4G 17 cellular packets define the source IP address 445, i.e. the client device, as IP Ci, and the 18 destination IP address 446 of the SDNP gateway as IP Mo,o. WiFi packet A, routed at the 19 PHY layer over a connection comprising WiFi link 29A, includes xmitter MAC radio source address 236 comprising MAC Ci,, MAC radio receiver destination address 235 21 comprising MAC W, and MAC network destination 237 comprising MAC R. Cellular B, 22 routed as the PHY layer connection realized by WiFi link 29B, includes MAC source 23 address 300B comprising MAC C1,2, and MAC destination 330B comprising MAC BS. 24 The change in the source media address from MAC Ci, to MAC C1,2 redirects the transmission from the WiFi LAN to a cellular network. In operation, data packets from 26 SDNP client device 1400 are fragmented then apportioned into SDNP payload A and 27 SDNP payload B in accordance with SDNP algorithms and shared secrets. Fragmented 28 data transport across the multi-PHY Last Link occurs with SDNP payload A carried by 29 WiFi packet A across WiFi link 29A and SDNP payload B carried by cellular packet B on cellular link 28B.

1 Another form of multi-PHY communication involves physical mediums capable 2 of supporting many channels at different frequencies and using distinct protocols for 3 different data packets. Such an implementation can be facilitated using a DOCSIS3-based 4 cable distribution system executing SDNP software. The OSI communication stack for a SDNP enabled DOCSIS3 cable distribution system is illustrated in FIG. 63 including 6 Layer 1 PHY connectivity, the Layer 2 data link, and an overlying Layer 3 network for 7 both the cable modem termination device CMTS 101 as well as examples of cable 8 connected devices, e.g. cable modem CM 103 or set top box STB 102. Specifically, cable 9 modem termination system device CMTS 101 and its associated stack 378 contains a Layer 1 PHY network interface 361 connected to cloud servers 22 and Internet 20, or 11 alternatively to a video headend, IPTV system, or VoIP system (not shown). The 12 combination of network interface 361 and data link layer 366 are included in the device 13 interface communication stack 378 of CMTS 101. On data link Layer 2, data is passed 14 from the network interface communication stack to the cable network interface communication stack through forwarding function 370, specifically into link level control 16 LLC 369. Link level control 802.2 LLC 369 comprises a hardware-independent protocol 17 defined in accordance with IEEE specification 802.2. The packet data is then modified by 18 link security 368 to provide rudimentary packet security, primarily to prevent 19 unauthorized viewing of content such as pay-per-view unicast broadcasts. The Layer 1 PHY cable interface 362 then sends the data frames over distribution 21 network 102 comprising either coaxial cable 104 or optical fiber 91 to the corresponding 22 Layer 1 PHY cable interface 363 within cable modem CM 103 or set top box STB 102. 23 Cable interface 363 represents the PHY layer of the cable network interface shown as 24 OSI communication stack 379 of cable modem CM 103 or set top box STB 102. Upon receiving a data packet, cable MAC interface 371 then interprets the cable MAC 26 addresses, passing its payload to link security 372 for decryption and ultimately to 27 hardware independent link layer control 802.2 LLC 373 for interpretation. The input data 28 to the CM or STB cable network communication stack is then passed through transparent 29 bridging 374 to the CM or STB device interface communication stack, specifically to device independent link layer control 802.2 LLC 375 in accordance with the specification 31 for IEEE 802.2. The packet is then passed to either HSD & IPTV MAC block 376 or to

1 WiFi 802.11 MAC block 377 to update the packet's MAC addresses. In the case of WiFi 2 communication, the data packet is then passed from 802.11 MAC block 377 to WiFi 3 PHY Layer 1 radio interface 365 for transmission on WiFi antenna 26. In the case of 4 wireline connections, the data packet is then passed from HSD & IPTV MAC block 376 to Ethernet or HDMI interface block 364 for connecting to TV 39 or desktop 36. 6 The PHY and data link layer as described establish connections from a CMTS to 7 any number of cable modems (CMs). Within CMTS communication stack 378 and within 8 CM communication stack 379, data packets are prepared within OSI Layer 3 layers 360A 9 and 360B, respectively, as IP datagrams IPv4, IPv6 or ICMPv6 using IP addresses recognized by the cable network or by the Internet's DNS name servers. In Last Mile 11 communication SDNP datagrams using IPv4 or IPv6 data packets with SDNP source and 12 destination IP address are generally not used because connected devices not enabled by 13 SDNP software or firmware have no ability to interpret the SDNP datagram routing 14 addresses. Transport Layer 4 operation within the cable modem network varies by device. In 16 the case of CMTS 101, Layer 4 transport layer 1420 of OSI communication stack 378 17 exclusively employs UDP because its operation necessitates real time communication, 18 e.g. the streaming of video data. From this perspective, cable communication 102 is more 19 like the SDNP real time network than the Internet is. Because the cable modem has interoperability with both the Internet and the cable network as a client, i.e. end 21 communication device, Layer 4 transport layer 1420B in OSI communication stack 379 22 of CM 103 or STB 102 uses UDP for real time operations and employs TCP for Internet 23 data. Such use is problematic for OTT carriers using VoIP over the Internet, as the cable 24 network will interpret the IP datagrams as data, automatically employing TCP and the transport protocol and degrading real time communication QoS, latency, and propagation 26 delay. This issue does not arise in SDNP enabled cable modems - in cases where the CM 27 or STB is operating SDNP firmware or software, the SDNP software contextually 28 decides when the use of TCP is warranted (for software and files) and when it is not, i.e. 29 for real time data. The application layers, namely OSI Layer 5 through Layer 7, sit atop Layer 31 transport operations 1420A in CMTS 101 and atop transport layer 1420B in CM 103 or

1 STB 102. In CMTS 101 these applications typically involve communication tasks such as 2 SNMP 1431A, Internet-standard protocol for collecting and organizing information 3 connected devices on IP networks. Other functions include DHCPv4 1432A and 4 DHCPv6 1433A. DHCP, an acronym for dynamic host configuration protocol is a protocol for both clients and servers to automatically supply an IP host with necessary 6 routing information including dynamically generated (non static) IP address, default 7 gateway and subnet mask. Although Internet generation specific, i.e. for IPv4 or IPv6, the 8 function of dynamic IP address generation, like a NAT gateway or SNMP, is generic and 9 equally applicable in DOCSIS3 cable systems for both CMTS 101 and CM 103 or STB 102. 11 The application layer implementation of the secure dynamic communication 12 network and protocol disclosed herein, when realized as SDNP firmware 1430A running 13 atop the CMTS 101 operating system can perform any number of unique tasks including: 14 • Operating as a pass-through without interpreting the SDNP 16 payload 1430 in which case CM 103 must be enabled to open and read the SDNP 17 payload, i.e. CM 103 must be a SDNP client. 18 • Operating as a Last Mile remote SDNP gateway, i.e. interpreting 19 the contents of a SDNP payload and converting the contents to a DOCSIS3 specific message (including link security) for forwarding to CM 103. In such 21 cases CM 103 need not be running SDNP client software or firmware. 22 • Operating as a Last Mile SDNP bridge, converting IP datagrams to 23 SDNP datagrams, and communicating the SDNP datagrams to CM 103. In such 24 cases, CM 103 must be running SDNP client software or firmware to connect to the SDNP-bridge, i.e. forming an adhoc SDNP "floating" network. 26 As shown, OSI communication stack 379 for CM 103 and STB 102 includes 27 numerous applications classified as OSI Layer 5 through Layer 7 including the 28 aforementioned communication related apps SNMP 1431B, DHCPv4 1432B, and 29 DHCPv6 1433B. Another function, the utility TFTP 1434B or "trivial file transfer protocol" is primarily used in DOCSIS3 as a means to download software and software 31 updates from the CMTS to cable modems and set top boxes throughout the cable

1 network. In cable networks, the HTTP 1435B or hypertext transfer protocol is primarily 2 for painting dynamic menus useful in smart TVs. Other applications (labeled by the 3 shorthand notation "Otr" 1436B) include gaming apps, diagnostics, IPTV apps, video 4 recording functions, and more. SDNP firmware 1430B running on CM 103 or STB 102 extends, HyperSecure Last Mile communication all the way to the user and Last Link 6 regardless whether CMTS 101 is running SDNP software or not. 7 FIG. 64 illustrates construction of a DOCSIS3 data packet adapted for delivering 8 SDNP payload 1430. As shown PHY Layer 1 comprises physical media device frame 9 390 of variable length and duration, containing data link Layer 2 MAC data comprising preamble 391, variable length payload or codewords 392 and guardtime 393. Preamble 11 391 contains either an upstream preamble or a downstream preamble, depending on the 12 direction of communication. In the case of an upstream preamble, preamble 391 contains 13 physical media device PMD header 398, MAC header 399A and data PDU 400A. In the 14 case of the downstream preamble, preamble 391 contains MPEG header 401, MAC header 399B and data PDU 400B. Both data PDU 400A in the upstream preamble and 16 data PDU 400B in the downstream preamble contain MAC destination address (DA) 17 403B and MAC source address (SA) 403A. The content of variable length payload 392 18 may comprise a short codeword 394 or a long codeword 397. 19 Short codeword 394 contains payload 395A comprising data A and error correction 396A containing FEC A. In the event of long codeword 397, the payload is 21 divided into multiple payload blocks 395A, 395B, and 395C carrying data A, data B, and 22 data C, respectively, with each payload containing its own error checking blocks 396A, 23 396B, and 396C including corresponding data FEC A, FEC B, and FEC C. After error 24 checking, the delivered data from DOCSIS3 comprises data blocks 395A, 395B and 395C in the case of a long codeword and only data block 395A in the case of a short 26 codeword. The combination of data A, data B, and data C merge into a contiguous IP 27 datagram, in this example an IPv6 datagram, containing IP source address 445, IP 28 destination address 446 and data field 435 containing SDNP payload 1430 and transport 29 header 436 containing Layer 4 data. In this manner DOCSIS3 flexibly delivers data over a cable network using packet-switched data protocol.

1 As shown in FIG. 65A the data packets are carried in multiple channels over a 2 hybrid cable-fiber network, i.e. at different frequencies. In DOCSIS 3.0, data channels 3 range from 5MHz to 1,002MHz including analog TV signals 1440 (triangles), QAM data 4 1441, and "diplexer" control channel 1443. In phase 1 of DOCSIS 3.1, the frequency range is extended to 1,218MHz and DOCSIS3.1 data channels 1442 are added to 6 facilitate OFDM modulation, primarily in a frequency band above the existing channels 7 assigned for QAM. 8 OFDM is preferred to QAM modulation methods because the channels can be 9 more tightly spaced. Comparing modulation schemes, QAM frequency distribution 1445A exhibits a wider tail in spectral content than OFDM frequency distribution 1445B. 11 Specifically, the spectral sideband width from fo to f-5o, i.e. the width from the carrier 12 edge to the frequency where the signal drops by -50dB, is 4.3 normalized frequency units 13 wide in QAM frequency distribution 1445A, but only 0.4 normalized frequency units 14 wide in the case of OFDM frequency distribution 1445B. Because the spectral width is narrower, more communication channels can be packed into the same spectrum 16 increasing the overall bandwidth and the maximum total data rate of the network. In 17 phase 2 deployment of DOCSIS 3.1, the frequency range is extended to 1,794MHz. 18 Many of the bands originally assigned for QAM data 144lare replaced by new channels 19 assigned explicitly for OFDM data 1442. In a DOCSIS-enabled cable network, one CMTS unit supports many CMs 21 managing the available channels. Although the CMTS can allocate downstream 22 communication and channel selection dynamically as needed, upstream communication 23 requires contention management to facilitate the case where multiple CMs attempt to 24 send data concurrently. As such, each modem must request an uplink channel from the CMTS before sending data. This process is shown in FIG. 65B comprising a sequence of 26 communication operations between CMTS 101 running SDNP app 1335L and CM 103 27 operating SDNP firmware 1335M. Routing of IP datagrams in multi-PHY 28 communication utilize IP addresses "IP CMTS" and "IP CMl" and multiple MAC 29 addresses, by example "MAC CMl" for CM 103 and "MAC CMTS1", "MAC CMTS2", "MAC CMTS3", and "MAC CMTS4" for CMTS 101. In the topmost illustration

1 showing a graph of frequency versus time, CM 103 sends a request to transmit RQST 2 1445A on a dedicated channel. 3 After receiving no response, a second RQST 1445B is sent resulting in a reply 4 from CMTS 101 on a different channel, in the form of MAP data packet 1446. The contents of MAP data packet 1446 instruct CM103 when to transmit and what channels it 6 can use for its upstream communication. After receiving the MAP data packet 1446, CM 7 103 sends its upstream data concurrently spread over two channels in uplink data packets 8 1447A and 1447B. The splitting of data sent concurrently over two channels shown in the 9 center illustration is referred to a channel bonding. Channel bonding is a means by which communication bandwidth and data rate between the CMTS and CM can be increased. It 11 is also a dynamic method to insure no available bandwidth goes unused. In the bottom 12 illustration, CMTS 101 replies by channel bonding four channels, namely 1448A, 1448B, 13 1448C, and 1448D and sending data concurrently but of differing durations. 14 In both upstream and downstream communication across the hybrid fiber-cable network, bandwidth is allocated dynamically among multiple channels, divided into small 16 time segments referred to as "minislots". FIG. 65C illustrates upstream communication 17 from CM 103 to CMTS 101. Such upstream communications generally comprise a 18 message or a request to transmit. In this example, data is sent over frequencies fi and f2

19 comprising five time minislots in total. As shown, minislots 1, 2, and 3 are sent at frequency fi during intervals K, (K+1), and (K+2) while minislots 4 and 5 are sent at 21 frequency f2 during intervals K and (K+1), but not during interval (K+2). Upstream data 22 packet 1450A, shown in abridged form, specifies the IP source address "IP CMl" and the 23 IP destination address of the Last Mile communication, i.e. "IP Mo,o", the gateway node 24 of the SDNP network hosted by server 1201A. For Last Link communication, upstream data packet 1450A specifies "MAC 26 CM" as the cable modem's source MAC address and specifies the PHY medium, in this 27 case the channel on frequency fi as the MAC destination "MAC CMTS1". Data packet 28 1450A containing SDNP payload A occupies three minislots in total, namely minislots 1, 29 2, and 3 even though together they carry a single data packet and payload. In contrast, minislot-4 and minislot-5 each contain only a single data packet each, i.e. 1450B and 31 1450C with corresponding data SDNP payload B and SDNP payload C. Like data packet

1 1450A, both packets 1450B and 1450C specify a destination IP address of the SDNP 2 cloud, specifically SDNP gateway node Mo,o. 3 For the MAC destination address, however, rather than specifying the same MAC 4 address and physical media as the first packet, both packets 1450B and 1450C stipulate a MAC destination address of "MAC CMTS2". This address can be used to specify that the 6 data packets 1450B and 1450C should be carried on a different frequency than data 7 packet 1450A - in this case frequency f2, not frequency fi. The actual values of the 8 frequencies are dynamically mapped by CMTS 101 and not specifically identified. A 9 DOCSIS3 enabled system thereby represents a multi-PHY solution whereby a single CMTS unit can communicate concurrently to a cable modem or set top box over multiple 11 frequencies and using multiple protocols such as 256 QAM or OFDM. 12 Rather than allowing the CM and CMTS to determine which data packets use a 13 common carrier channel or frequency as is the normal case for DOCSIS3 systems, in 14 accordance with the disclosed secure dynamic communication network and protocol for Last Mile communication, the SDNP client CM 103 specifies different MAC destination 16 addresses to force communication over multiple frequencies and channels, i.e. to force 17 multi-PHY operation. Because CM 103 data packets 1450A and 1450B/C stipulate 18 different destination MAC addresses, namely MAC CMTS1 and MAC CMTS2 19 respectively, the data packets automatically invoke multi-PHY operation over the Last Link. Alternatively if the CMTS facilitates another means by which to request unique 21 channel allocation, e.g. using a command and control request, then the use of the MAC 22 address to invoke multi-PHY communication may be substituted by the alternate means. 23 FIG. 65D illustrates downstream data flow from CMTS 101 to CM 103 24 illustrating the use of bonding to achieve high data rates in multi-PHY downstream communication. As shown, all data packets specify a source IP address of "IP CMTS", a 26 destination IP address of "IP CMl" and a MAC destination address of "MAC CMl". 27 Multi-PHY communication is controlled by specification of the MAC source address of 28 CMTS 101. As shown, data packet 1450G containing SDNP payload G specifies MAC 29 source address "MAC CMTS6" corresponding to communication at frequency fA carrying data in minislots 15 and 16. Data packet 1450H contains SDNP payload H and specifies 31 MAC source address "MAC CMTS7" corresponding to communication at frequency f7

1 carrying data in minislots 17 through 20. Data packet 14501 containing SDNP payload I 2 specifies MAC source address "MAC CMTS8" corresponding to communication at 3 frequency fs carrying data in minislots 21, 22, and 23. Finally, data packet 1450J 4 containing SDNP payload J specifies MAC source address "MAC CMTS9" corresponding to communication at frequency f9 carrying data in minislot numbers 24 6 and 25. In this manner related and unrelated data packets can be concurrently sent from 7 CMTS 101 to CM 103 using multi-PHY methods without channel contention or data 8 collisions with concurrent upstream data. 9 HyperSecure Call Routing - HyperSecure call routing made in accordance with the disclosed secure dynamic communication network and protocol may be performed 11 using one of three methods for command and control 12 • Tri-channel communication, where routing of a call or communique is 13 controlled using three sets of servers, namely the SDNP media servers for carrying 14 audio, video, or data files; the SDNP signaling servers for selecting the routing of a call, and a SDNP name server for storing the dynamic mapping of phone numbers to 16 their corresponding SDNP addresses, 17 • Dual-channel communication, where routing control of a call or 18 communique uses two sets of servers, namely the SDNP media servers for carrying 19 audio, video, or data files; and the SDNP signaling servers for routing the call, and for performing the function of a SDNP name server mapping of phone numbers to their 21 corresponding SDNP addresses, 22 • Single-channel communication, where the data transport, the route 23 planning, and the SDNP address map are all executed by a single set of servers. 24 In general, tri-channel communications offers greater immunity to cyber-assaults because no one set of servers contains all the information about a call. In every case 26 however, the SDNP network utilizes distributed processing to limit the information 27 contained within any given server. Furthermore, during data transport in single-, dual- or 28 tri-channel communication, the SDNP media servers connect to a fourth type of server 29 DMZ servers. DMZ servers are used for housing SDNP shared secrets needed for processing the SDNP data payloads, including scrambling, splitting, mixing, junk data 31 insertions and removals, and encryption. In operation, incoming data packets received by

1 a media server are delivered to the DMZ server where the data packets are modified and 2 passed back to the media server. The media server is unaware how the data packets have 3 been modified or what logic or algorithm was used to process the data. The executable 4 code and tables stored in a DMZ server are encrypted to prevent analysis of the code. Furthermore, DMZ servers operate offline with no connection to the network or Internet. 6 The following graphics illustrate one exemplary implementation of tri-channel 7 SDNP communications and the sequence used to initiate a call or send a file over the 8 network. Operation of dual-channel communication can be considered as a minor 9 modification to tri-channel communication where the SDNP name server functions are merged into the signaling servers. Single-channel communication comprises the 11 integration of all three operations into a network of multifunction servers operating as 12 SDNP communication nodes. 13 Although fragmented data transport within the SDNP cloud is generally 14 performed using dynamic meshed routing, Last Mile communications offers fewer routing options, specifically where successive data packets may be either (i) routed to a 16 single SDNP gateway, i.e. as single-route Last Mile communication, or alternatively (ii) 17 routed to multiple SDNP gateways, i.e. as multi-route Last Mile communication. Other 18 Last Mile routing choices include dynamic source addressing and multi-PHY Last Link 19 connectivity. These delivery options are specified within the IP data packets generated in the signaling servers. Despite the fact that these SDNP data packets specify their source 21 and destination IP and MAC addresses, the precise path that a particular data packet takes 22 in the Last Mile is not known. Instead the intermediate path is determined by operation of 23 the routers, devices owned by local network operators, mobile network operators, and 24 network service providers serving the Last Mile, and not by the SDNP signaling servers. Last Mile communication is therefore analogous to a jump rope where the two ends are 26 fixed but where a myriad of uniquely shaped paths connect them. 27 Reiterated for clarity's sake, the term single-route, multi-route, and meshed-route 28 communication refers to the path of media packets, i.e. the path "content" traverses 29 between callers, while the terms tri-channel, dual-channel, and single-channel communication refers to the command and control system used to govern transport over 31 the network of SDNP nodes. Given the foregoing, the following set of illustrations depict

1 the sequence of steps, i.e. the "process", used in making a call or initiating a communique 2 in accordance with the disclosed secure dynamic communication network and protocol. 3 FIG. 66 illustrates an abstract representation of a single-route Last Mile network 4 for tri-channel communication comprising a SDNP client 1600, IP routers 1602A, 1602B, and 1602C, signaling server 1603A, SDNP name server 1604A and SDNP gateway 1601. 6 These computer servers host SDNP communication nodes used for facilitating network 7 communication with network node names and IP addresses as shown comprising SDNP 8 client Ci,, routers R, SDNP signaling server node S, SDNP name server node NS, and 9 SDNP gateway node Moo. Network connection 1610 facilitates a Last Link between client Ci, and its nearest router 1602A; network connection 1611 facilitates a gateway 11 link between SDNP gateway Mo,o and its nearest router 1602B; network connection 1612 12 facilitates a gateway link between SDNP signaling server 1603A and its nearest router 13 1602C; and network connection 1616 interconnects to topologically adjacent routers 14 1602A and 1602C. Since the IP addresses of the routers are not used in IP datagrams either as a source or destination address, the nominative "R" is shared by all routers on 16 Layer 3. In the case of Layer 1 and Layer 2 descriptions, each router has a unique 17 identity, but this aspect is not germane to describing IP network Layer 3 call routing. 18 SDNP signaling server 1603A (node S) connects to SDNP name server 1604A (node NS) 19 over network connection 1613 and to SDNP cloud nodes Mo,n over a number of network connections 1614. Signaling server 1603A also connects to other signaling servers (not 21 shown) over network connection 1615. 22 Using the SDNP network, placing a call, i.e. establishing a "session", involves the 23 following sequence of steps initiated from the SDNP client making the call, i.e. the 24 "caller" 1. SDNP call (or call out) request 26 2. SDNP address request 27 3. SDNP address delivery 28 4. SDNP routing instructions 29 5. Commence SDNP call (or call out) The first step, the "call request" is illustrated graphically in FIG. 67 where the 31 caller, client 1600 with address "IP Ci," contacts signaling server 1603A at address "IP

1 S" over the paths 1610, 1616, and 1612 with IP datagram 1620. The datagram's 2 command and control payload 621 contains Layer 4 data transport using TCP to insure 3 data accuracy, and specifies a number of requested call parameters including delivery, 4 urgency, security credentials, and the contact information of the "callee", the party being called. In the case of a call to another SDNP client, i.e. a "SDNP call", this contact 6 information comprises a confidential identification (CID) of the client being called, data 7 present in the client's SDNP phone directory. In the case of a "call out", a call to a party 8 who is not an SDNP client, the contact information comprises a phone number. While the 9 CID of a SDNP client is intrinsically anonymous and known only to the SDNP name server, the phone number is not disguised. To protect the privacy of the party being 11 called, the phone number in the C&C payload is encrypted. Alternatively the entire C&C 12 payload 1621 can be encrypted. While C&C payload 1621 can be in the form of 13 ciphertext, the IP addresses of IP datagram 1620 cannot be encrypted, otherwise routers 14 1602A and 1602C cannot route the datagram. The second step, the "SDNP address request" is illustrated in FIG. 68 where the 16 SDNP signaling server with address "IP S" contacts SDNP name server at address "IP 17 NS" over the path 1613 with IP datagram 1622. The datagram's command and control 18 payload defines Layer 4 data transport as TCP and contains either the CID or encrypted 19 phone number of the party being called. In the case of a SDNP call, name server 1604A converts the CID into a SDNP address of the client being called. In the case of a call out, 21 name server 1604A decrypts and converts the phone number of the party being called 22 into the SDNP address of the SDNP gateway closest to the location of the callee. As 23 shown in FIG. 69, name server 1604A then passes the SDNP address of the client or 24 gateway in IP datagram 1623 from source address "IP NS" to signaling server 1603A at address "IP S". 26 Signaling server 1603A then utilizes the SDNP addresses of the caller and the 27 callee to route a call between them, either as a HyperSecure connection if the callee is an 28 SDNP client, or to the nearest SDNP gateway if the callee is not an SDNP client. The 29 process used to prepare routing instructions and distribute them to every media node required to complete the caller's connection is shown in FIG. 70. As shown, the caller's 31 delivery request contained in the delivery and urgency fields of the C&C payload 1621A,

1 once validated against account information, is used to select the delivery method of the 2 datagram, as shown by operation 1650. Delivery methods comprising either normal, VIP, 3 guaranteed, or special delivery, affect the routing of packets or sub-packets (if the packets 4 are split or fragmented). In VIP delivery, for example, the fastest routes are used for data transport, while loading of the same routes by other clients is minimized. In guaranteed 6 delivery, duplicate data packet fragments are sent across the network, i.e. using 7 redundancy, to insure timely delivery of the fastest packets and ignoring late arrivals. 8 Combined with the SDNP address data from C&C payload 1623A, operation 1651 then 9 maps the optimal routes from the caller to the SDNP address of the callee or to the closest gateway if the callee is not an SDNP client. Urgency request data contained within C&C 11 payload 1621A is used to select package urgency operation 1652, including in order of 12 decreasing propagation delays - snail delivery (no need to hurry), normal delivery, 13 priority delivery, and urgent delivery. 14 The urgency request information is then used to select routing and zones for sub packet routing by operation 1653. These parameters, along with any applicable security 16 credentials 1621B, are combined to synthesize the routing command and control packets 17 through operation 1660. These C&C data packets are delivered to the Last Mile's 18 participating communication nodes using TCP specified Layer 4 transport, but contain 19 routing information that when used in delivering real time data employ UDP as its Layer 4 transport protocol. For example, Last Mile routing made in accordance with zone Ul 21 security credentials is generated as IP datagram 1625 containing C&C payload 1626 used 22 for routing data from client node Ci, to SDNP gateway node Mo,o. IP datagram 1625 is 23 delivered to the SDNP client using TCP data transport, but the C&C payload 1626 24 entitled "Last Mile routing Ul" contains data used by to route packets in real time, necessitating the use of UDP as its Layer 4 transport mechanism. SDNP C&C packet 26 synthesis operation 1660 also generates numerous other C&C messages delivered as TCP 27 data packets to nodes within the SDNP cloud. One example of a cloud instruction data 28 packet is IP datagram 1627A containing C&C payload 1628A used for routing data from 29 SDNP Mo,oto SDNP Mo,. As shown in FIG. 71, these SDNP routing instruction packets are distributed to the media nodes including client node Ci, over the serial connections

1 1612, 1616, and 1610 and to SDNP gateway node Mo,o and to other nodes within the 2 SDNP cloud over connections 1614. 3 Commencement of the call is shown in FIG. 72, where media SDNP datagram 4 1630 containing SDNP data, e.g. sound, video, text, etc. is appended onto an P header comprising C&C data packet 1626, and routed from IP Ci, to IP Mo,o from SDNP client 6 1600 across Last Link network connection 1601 to routers 1602A and 1602B and finally 7 to SDNP gateway 1601 across gateway link 1611. Together the identifying tag, security 8 zone, preamble, and SDNP data fields constitute the payload of a SDNP media packet 9 contained within media SDNP datagram 1630. Routing of the aforementioned SDNP call, i.e. a HyperSecure call from SDNP 11 gateway Mo,o to a SDNP client C7,1 comprising cell phone 32 running SDNP app 1335A 12 is shown in the simplified network diagram of FIG. 73A. SDNP datagram 1631A 13 containing media SDNP payload A and header 1628A is routed between media nodes 14 with SDNP addresses Mo,o and Mo,. Note that SDNP gateway 1601 has two addresses IP address "IP Mo,o" for Last Mile communication, and SDNP address "SDNP Mo,o" for 16 communication within the SDNP cloud. The content of each SDNP datagram changes as 17 the packet traverses the SDNP cloud so that the content - sound, video and text contained 18 within SDNP media payload A, B, and C are distinctly different and may include content 19 from twenty different conversations or communiques. The mechanisms of data routing and packet security within the SDNP cloud are disclosed in the above-referenced U.S. 21 Application No. 14/803,869, titled "Secure Dynamic Communication Network and 22 Protocol" which describes how the content and encryption of the data packets moving 23 anonymously through the SDNP cloud change dynamically and continuously, only 24 converging in the client's device. Accordingly, SDNP datagram 1631B containing media SDNP payload B and 26 header 1628B is routed between media nodes with IP addresses IP Mo,4 and Mof. Data 27 exiting the SDNP cloud through SDNP gateway 1601B is converted from a SDNP 28 datagram into P datagram 1632. The IP datagram 1632 with header 1628C and SDNP 29 media payload C utilizes security credentials for zone U2, which is the zone comprising the Last Mile. TP datagram 1632 is then routed over the Last Mile over wired or fiber link 31 24 to network router 27, and thereafter routed over cellular network 25 and cellular link

1 28 to cell phone 32. Because cell phone 32 is a SDNP client, communications over the 2 Last Mile remain HyperSecure. In this simplified example, all data packets exiting the 3 cloud onto the Last Mile are routed from a single SDNP gateway 1601B. In reality, more 4 than one SDNP gateway may be employed in Last Mile data routing. Last Mile communication for a "call out" is shown in FIG. 73B. Although routing 6 through the SDNP cloud employs the same SDNP datagrams 1631A and 1631B as used 7 in a call to an SDNP client, SDNP gateway 1601B is the last server running SDNP 8 software. Last Mile communication in a call out therefore uses IP datagrams with non 9 SDNP payloads, i.e. IP datagram 1635 is routed from gateway IP Mo,o to PSTN at IP address IP C 7 ,9 carrying sound in the form of VoIP. PSTN then converts the VoP call 11 format into a conventional phone call using a phone # and analog sound in sound packet 12 1636. In such cases, the Last Mile does not constitute HyperSecure communication. 13 In multiroute Last Mile communication, shown in FIG. 74, command and control 14 data packets distributed by SDNP signaling server 1603A include C&C data packet 1625X sent to client 1600 over data links 1612 and 1610, C&C data packet 1627X sent to 16 SDNP gateway 1601X over data link 1614X, and C&C data packet 1627Y sent to SDNP 17 gateway 1601Y over data link 1614Y. Other C&C data packets (not shown) are sent over 18 data links 1614X to other servers hosting media nodes. C&C data packet 1625X sent 19 from an address "IP S" to address "IP Ci" containing a C&C payload comprising Last Mile routing Ul. Last Mile routing U includes two different routing instructions - one 21 from "IP C,i" to "IP Mo,o" with tag 1 and preamble 1, and another from "IP Cii" to "IP 22 Mo,i" with tag 2 and preamble 2. Shown by example, C&C data packets sent to 23 communication nodes within the SDNP cloud, include those sent from "IP S" to "IP 24 Mo,o" containing instructions SDNP Cloud Routing 1, and those sent to "IP Mo,i" containing SDNP Cloud Routing 2. 26 SDNP Group Calls - Last Mile media packet routing from SDNP client 1600 to 27 multiple SDNP gateways, shown in FIG. 75A, includes two data packets 1630X and 28 1630Y comprising respective headers 1626X and 1626Y and SDNP media payloads 29 SDNP data X and SDNP data Y. Data header 1626X with tag 1 and preamble 1 is routed from address "IP Cii" to address "IP Moo" while data header 1626Y with tag 2 and 31 preamble 2 is routed from address "IP Cii" to address "IP Mo,i".

1 Data flowing in the reverse direction from the SDNP cloud to the client using 2 multi-route communication, as illustrated in FIG. 75B, includes data packet 1630U 3 containing header 1626U, tag 8, preamble 8, SDNP data U, source address SDNP 4 gateway address Mo,o and destination address "IP Coo". Concurrently, the data also includes data packet 1630V containing header 1626V, tag 9, preamble 9, SDNP data V, 6 source address SDNP gateway address Mo,, and destination address "IP Coo". The SDNP 7 application program running in SDNP client 1600 then combines the incoming data 8 packets SDNP data U, SDNP data V, and others to recreate the message text or voice 9 (sound). The C&C data packet delivery of routing instructions can be extended to initiate 11 three-way or group calls, group messaging, and other multi-client communications. In 12 such group communiques or "conference calls", a client message is sent to multiple 13 recipients concurrently. This group function is invoked by the caller whose request for a 14 group call first defines the group of clients to be contacted, then by the signaling server that instructs the required media nodes how to handle routing of data packets associated 16 with the specific group call. An example of group call routing instructions is shown in 17 FIG. 76 where signaling server 1603P communicates routing instructions over data link 18 1614A to SDNP client 1600A and over data links 1614Z to numerous media servers 19 1600Z within the SDNP cloud. As such, TCP data packet 1627A containing Last Mile routing U1 is delivered 21 from signaling server 1603P at address "IP SI" to SDNP client at address "IP Cii" to 22 "set up" the group call with the caller. C&C data packets represented by exemplary TCP 23 data packet 1627Z are concurrently distributed throughout the SDNP cloud for zone ZI 24 over data links 1614Z from signaling server address "IP SI" to various destination addresses "IP Mo,y" where y represents a integer variable. Collectively, the SDNP cloud 26 routing instructions establish packet routing from the caller's gateway throughout the 27 SDNP cloud to two or more other SDNP gateways located nearest the SDNP clients 28 being called. 29 As shown by example, the other SDNP clients may be located in different geographic regions and may be within separate security zones, for example zones U7 and 31 U9. In some cases, these clients may be sufficiently far from signaling server 1603P that

1 another signaling server 1603Q may be used to plan packet routing for these SDNP 2 clients. Signaling server 1603Q communicates routing instructions in zone U9 to SDNP 3 client 1600M over data link 1614M and to SDNP client 1600L over data link 1614L. 4 C&C data packet 1625M, for example, communicates Last Mile routing instructions U9 from signaling server at "IP S4" to SDNP client 1600M at its address "IP C9,". Another 6 C&C data packet (not shown) is similarly sent to the SDNP client at address "IP C9,4". 7 Data packet 1627H, containing instructions for Last Mile Routing U7, is sent over data 8 link 1614H from signaling server 1603Q at "IP S4" to client 1600H at address "IP C7,1". 9 Signaling servers 1603P and 1603Q at nodes S Iand S4 also exchange information as C&C data packets over data link 1613Z. This information is used to 11 establish which portions of the routing is to be performed by signaling server 1603P and 12 which portions will be performed by signaling server 1603Q, essentially dividing the 13 routing task across multiple signaling servers. In the example shown, signaling server 14 node S Imanages the Last Mile routing for zone U1 and for the SDNP cloud while signaling server node S4 manages Last Mile communication in zones U7 and U9. 16 Data routing during a call or communique is shown in FIG. 77A where voice 17 carried by SDNP data 1 in data packet 1630A is routed by header 1626A from the caller 18 with IP address "IP Cii" to the nearest SDNP gateway media node Mo,o. The data packet 19 is re-packeted for SDNP cloud transport and sent to gateway media nodes Mo,4 and Mos. The path packet routing takes within the SDNP cloud is unknown to any of the 21 conference call participants, lacking any central control and varying dynamically with 22 network conditions. In this example, all SDNP data packets within the SDNP cloud 23 utilize fragmented meshed data transport with anonymous addressing and dynamic 24 encryption, as well as using dynamic scrambling, mixing, splitting, with junk data insertions and deletions. In the example shown, the cloud transport directs incoming 26 communication at SDNP gateway node Mo,o to other gateways, in this case SDNP 27 gateway nodes Mo,4, and Mos. 28 Data packet 1630H carrying the caller's voice, i.e. SDNP data 1, exits gateway 29 node Mo,4 and is routed using header 1626H from media node at "IP Mo,4" to client 1600H at "IP C 7 ,i" using zone U7 security credentials. Header 1626H was supplied to the 31 client 1600A within C&C data packet 1627A prior to preparing the media data packet, as

1 described in FIG. 76. In this manner, every media packet carrying real time data can be 2 prepared without delay when the content is ready for data transport. In real time 3 networks, high QoS depends on timely routing of dynamic data. Otherwise unacceptably 4 long propagation delays may result. Once routed through the SDNP cloud, SDNP data 1 payload is delivered to zone 6 U9 conference call participants, namely SDNP-clients 1600M and 1600L, from gateway 7 media node Mos to client IP addresses "IP C9," and "IP C9,4". These Last Mile data 8 packets 1630M and 1630L contain headers 1626M and 1626L specifying the identifying 9 packet tags tag8 and tag9 used to recognize content associated with the same conversation, preamble 9 information used for carrying SDNP embedded instructions, 11 keys, seeds, etc. and a "L4" data field used for stipulating Layer 4 transport as UDP. 12 Although data routing instructions delivered by the signaling server utilize a TCP 13 transport protocol to insure accuracy, media packet content represents real-time data, and 14 therefore beneficially utilizes UDP Layer 4 protocols instead of TCP. FIG. 77B illustrates the same conversation where content from zone U7 client 16 1600H occurs - that is when client C7,1 begins speaking. To contrast this data to voice 17 content from client Ci, the payload is identified within all the data packets as "SDNP 18 data 5". Aside from a unique payload, the only change from the prior schematic is that 19 the Last Mile source and destination IP addresses for data packets 1630H and 1630A are swapped. Specifically, for the zone U7 SDNP user the source IP address for data packet 21 1630H changes to IP C7 , and its destination becomes the SDNP gateway address IP Mo,4. 22 For zone U1 the callee destination IP address for data packet 1630A changes to IP Ci, 23 and its source address becomes the SDNP gateway address IP Mo,o. It should be 24 understood that several conference call participants may be speaking simultaneously and that data packets from SDNP client node Ci, sent to the other call participants including 26 client node C 7,1 may occur concurrently to client node C7, replying to client node Ci. 27 At the network level 3 of Last Mile communication, no data collisions of 28 opposing direction traffic occur. At the physical and data link layers 1 and 2, however, 29 Last Mile communication may involve time multiplexing to avoid contention for the same communication link. This mediation occurs, however, with such rapidity that the 31 communication likely appears to be full duplex with no delay in voice packets. Note that

1 in both FIG. 77A and FIG. 77B, the direction of data flow shown for zone U9 clients 2 remains unchanged, i.e. data flows from the cloud to the client. In FIG. 77C however, 3 zone U9 client node C9, begins speaking. In this case client nodes C9,4, Ci, and C7,1 all 4 become recipients of the voice, i.e. SDNP voice data 6. In an alternative embodiment shown in FIG. 78, a group call may comprise a mix 6 of SDNP calls to SDNP clients and of "call out" calls to regular phone numbers. In a 7 manner similar to the call or communique shown in FIG. 77A, voice carried by SDNP 8 data 1 in data packet 1630A is routed by header 1626A from the caller with IP address 9 "IP Cii" to the nearest SDNP gateway comprising media node Mo,o. The data packet is re-packeted for SDNP cloud transport and sent to gateway media nodes Mo,4 and Mos. 11 In the example shown the cloud transport directs incoming communication at 12 SDNP gateway node Mo,o to other gateways, in this case SDNP gateway nodes Mo,4, and 13 Mos. Data packet 1630H carrying the caller's voice, i.e. SDNP data 1, exits gateway node 14 M,4 and is routed using header 1626H from media node at "IP Mo,4" to client 1600H at "IP C 7 ,i" using zone U7 security credentials. SDNP data 1 payload is also delivered to 16 conference call participants through gateway media node Mos. Last Mile communication 17 from this SDNP gateway comprise two different types of connections, specifically a 18 HyperSecure connection to SDNP-client 1600M and an unsecured "call out" connection 19 to PSTN 1 comprising a conventional phone system not employing VoIP or packet protocols. Last Mile data packet 1630M delivered to zone U9 SDNP client at address "IP 21 C 9 , 1contains header 1626M specifying the identifying packet identifier "tag 9" used to 22 recognize content associated with the same conversation, preamble 9 information used 23 for carrying SDNP embedded instructions, keys, seeds, etc. and a "L4" data field used for 24 stipulating Layer 4 transport as UDP. Gateway node Mos also sends an IP packet 1635 to PSTN 1 at the address IP C7,9. 26 Rather than carrying the payload comprising SDNP data 1, in this case the IP payload has 27 been converted into a VoIP sound package, one that could be intercepted by packet 28 sniffing. The phone switch system, PSTN 1 then converts this unsecured IP packet into 29 an analog POTS phone connection to phone 37 shown by POTS data 1636 comprising the phone number being called followed by a continuous analog circuit connection 31 between phone 37 and PSTN 1. Because this and any other call out connections are not

1 HyperSecure, the content carried by the call out Last Link is at risk for hacking, wiretaps, 2 and other surveillance techniques. Unless some hierarchical structure defining access 3 privileges of the clients is implemented, the security of the entire call is compromised by 4 the weakest link, meaning everyone on a group call can hear everything. This point is exemplified in the table shown in FIG. 79A, where a group call 6 comprises HyperSecure participants on SDNP network client nodes Ci, C7,1, C9,i, and 7 C9,4, along with call out participants at phone numbers "Ph #1" and "Ph #2". As shown, 8 SDNP client Ci, is the group host, SDNP clients C7,1, C9,i are participants, meaning they 9 can listen and talk, and SDNP client C9,4 is a "listener" meaning they can listen to the call but cannot talk or be heard by the participants. The participant at call out phone number 11 "Ph #1" is also a participant able to listen and talk, while the caller at "Ph #2" is 12 authorized only as a call out "listener", not enabled to talk on the group call. The group 13 host prescribes these listen talk privileges, i.e. the user authorization, at the time the call 14 is set up. Referring again to the table in the column entitled regular call, please note that 16 everyone on the group call, i.e. callers approved by the host, has the ability to listen to the 17 call. Callers attempting to hack into the call and not approved by the host have no means 18 to connect or force their way onto the call or even the ability to determine a call is 19 transpiring. The same methods are applicable to group chats where participants can read and write messages, but view only members can only read the comments but cannot 21 interject their own text onto the chat. 22 Using authentication and identity verification for controlling network access made 23 in accordance with this disclosure, the SDNP system offers privacy features not available 24 in conventional group chats and group calls. This feature is invoked by selecting private mode, e.g. example by clicking a lock symbol or other privacy icon before texting or 26 speaking. In such cases, the communication is sent only to SDNP clients who are 27 authenticated and not to SDNP clients who have not yet confirmed their identities 28 through authentication and not to any call out listeners or participants on unsecured 29 devices. This point is clarified in the aforementioned table where, in a private call under the column labeled "Unauthenticated SDNP Client," all group call clients have both their 31 microphone and speaker muted while in the column labeled "Authenticated SDNP

1 Client," all SDNP clients can listen, participants Ci, C7,1, and C9,i can also talk, but all 2 call out devices have both their microphone and speakers muted, meaning only an 3 authenticated SDNP client can hear or comment in private mode. In this way, a group call 4 with a mix of SDNP clients of assured identity, and with call out connections with unknown parties can mutually participate in the public portion of a call but without 6 revealing confidential information to the call out devices. The "call out" callers are 7 removed from private discussions simply by having any SDNP participant click their 8 private icon before speaking or texting. At the end of the private discussion, the private 9 button is released and they are reconnected. During the time the call out callers are disconnected, i.e. essentially placed "on hold", the SDNP system can either play waiting 11 music, go silent, or play white noise (like ocean or rain sounds). 12 Text messages in a group chat can also be managed in the same manner. In a 13 regular group chat all text messages are sent to the SDNP app on SDNP client devices 14 and sent by SMS text message to all call out chat members. Text messages can be sent only by participants. Text messages sent from "Listeners" or "Read Only" chat members 16 are ignored and will not be forwarded to the chat group. If a participant clicks the lock or 17 privacy icon before sending a message, the message will be sent only to SDNP clients 18 and not to any call out clients. For SDNP clients receiving a private message, if they have 19 authenticated their identity the message will visible for reading. If they have not authenticated their identity, the message will be obscured, covered, hidden, or 21 represented by an icon, e.g. a lock, until the viewer performs an authentication to confirm 22 their identity. 23 By combining authentication of identity with privacy privileges regulated by 24 SDNP network system authorization, hacking the device is insufficient to open a private text or listen to a private call, even in group chats and group calls. This feature cannot be 26 guaranteed by relying only on device security parameters - information that can be 27 hacked locally. System parameters are much harder to trick because fake security and 28 identity credentials will not match the system logs and will be rejected as invalid SDNP 29 clients. An additional degree of privacy can also be added in executing group calls and 31 group chats. This unique embodiment of the HyperSecure Last Mile described in the

1 table shown in FIG. 79B is referred to herein as a hyper-private call or a hyper-private 2 chat. Hyper-privacy requires a caller or message conform to four criteria: 3 • All recipients of the communique on the group call must be an 4 SDNP client, not a call out device, • The call or text must be selected apriorias a hyper-private 6 communique, whether a call, text, image, etc. 7 • The recipient of the communique on the group call or chat must 8 have authenticated their connection to insure their identity 9 • The recipient of any hyper-private communique must be preselected as a "private" participant or private listener. 11 Although the first three criteria are essentially the same as those in the 12 aforementioned example of private parties in a group call, the fourth criterion, the 13 requirement that any caller eligible to receive hyper-private calls or text must be loaded 14 on a predefined list of clients as a "private" SDNP client, is unique and further limits access to sensitive information. For example, as shown in tabular form, SDNP participant 16 clients Ci and C7,1, and SDNP listener client C9,4 are all designated as "private" parties 17 in the group call. In contrast SDNP client C9, is only designated as a participant but not 18 as a private participant. By definition, no call participant or listener can be registered as a 19 private party. As in the previous example, during a regularcall all participants, i.e., SDNP 21 clients Ci,, C 7 ,, and C9, and call out participant Ph #1, can hear all conversations and 22 read all text messages as well as talk or text at any time, while "listeners," comprising 23 clients C9,3 and Ph #2, can hear all conversations and see texts but cannot talk or send 24 messages in the group call or chat. In a hvper-private call, however, selecting a switch or icon to designate a hyper-private communique automatically blocks not only all 26 unauthenticated parties on the group call or chat, but it also disables any party other than 27 "private" parties. It also disables all call out connections and all unauthenticated users. So 28 in operation, when any private participant selects the privacy icon, only private 29 participants (including the private group host), can see, read, talk or text to the group. All other parties have their microphones and speakers muted, and likewise are unable to 31 receive or send texts or attachments to the group. Specifically, in in hyper-private mode,

1 once authenticated, only clients Ci, andC 7 ,1 can both listen and talk as well as read and 2 send text while private clientC9,4can only listen to a conversation or read group text. 3 With the above Last Mile routing control capabilities, group calls and group chats 4 can be managed in any number of ways. For example, the group call host can determine who can join the call or group, who can talk and text, and who can only listen and read. 6 In a standard private call, selecting the private mode enables all SDNP clients, once 7 authenticated, to engage in communiques with the same privileges they had during 8 standard non-private group communication. In the hyper-private mode, only SDNP 9 clients defined as private participants and private listeners can communicate during hyper-private mode operation. 11 Selection of who is qualified to be part of a hyper-private communique, i.e. who 12 is identified as a private participant or listener, and who is not, can be established in 13 several ways. In ad hoc hyper-private group communication, the group host decides who 14 is a private caller and who is not. In SDNP "system defined" hyper-private group communication, the SDNP network operator decides in advance who is private caller and 16 who is not. In rules-based hyper-private group communication, the SDNP network has 17 defined rules to determine who is eligible to be a private caller and who is not. These 18 rules may be based on a company employment list, e.g. where only vice-president and 19 higher may participate in a hyper-private call. In government and security organizations, the criteria may be set by national security clearance, passport number, police badge 21 number, etc. The SDNP-enabled Last Mile communication methods defined herein can 22 support any of these exemplary scenarios, or employ any other criteria to bifurcate a 23 population into two groups, thereby establishing those that have hyper-private 24 communique access and those that do not. While the concept can be extended to more than one group, hierarchical access 26 criteria are generally more applicable to dispatcher-based professional communication 27 systems than to telephony. The application of SDNP methods for professional 28 communications will therefore not be addressed further in this application. 29 One challenge for group calls is the problem of everyone trying to talk at the same time. Overlapping speech is confusing, hard to hear, and may also result in unwanted 31 static. This issue can be remedied by using the push-to-talk feature, a function emulating

1 a walkie-talkie or CB radio. In push-to-talk or PTT operation only one participant can be 2 speaking at a time. When a participant wishes to talk, depressing a switch mutes all other 3 on the network microphones putting every other party in the group call into a listen only 4 mode. As shown in the table of FIG. 80A, in a regular PTT conversation when the host depresses the PTT button, as shown in the column labeled Host PTT, they take priority 6 over the group call and override every other caller, even those who have pressed their talk 7 button. All other callers, including call-out phone connections, automatically have their 8 microphones muted and become listeners only. Provided the host does not depress their 9 PPT button, then as shown in the column labeled "other PTT", then the PTT capability is surrendered to any other SDNP participant on a first come, first served basis. SDNP 11 nodes designated as listeners and call out devices such as C9,4 and Ph #1 can listen to the 12 PTT conversation but have their microphones muted during the entire group call. 13 Using the SDNP Last Mile capability for identifying callers that have 14 authenticated their identity to the network, the PTT feature can be extended to private push-to-talk functions. Whenever the privacy feature or icon is selected, all 16 unauthenticated parties are removed from the group call, muting their speakers and 17 microphones. Call out connections by definition cannot be authenticated and therefore are 18 muted as well. Muting is bidirectional, preventing the excluded parties from listening to 19 the conversation but also disconnecting the excluded participant's microphones as well. For those parties that are authenticated, operation precedes the same as a regular PTT, 21 where the host has priority to talk and otherwise any authenticated participant can invoke 22 the PTT talk feature on a first come, first served basis. 23 The table in FIG. 80B illustrates the concept of a hyper-private group call can be 24 extended to the PTT function. In regular operation, PTT functionality is identical to the previously described case. But in hyper-private mode, only authenticated parties who 26 have been previously designated as either private participants or private listeners can 27 engage in hyper-private conversations. For example in hyper-private mode, SDNP clients 28 C 9 , 1and C 9, 5are cut off from talking or listening because they were not previously listed 29 as private participants or listeners. Similarly, all call out connected devices are muted during hyper-private mode operation. In this way, access to the various parties in a PTT 31 group call can be explicitly controlled. Muting is the process of excluding some

1 participants (e.g. the call out listeners) from receiving data packets carrying the 2 conversation's sound while continuing to supply the data packets to participants who ae 3 not muted. In this disclosed method, data packets and individually sent to all participants 4 in normal conversation and only to a subset of the list when muting is activated by the client's user. 6 In an alternative embodiment data packets are sent in broadcast mode to all 7 participants in the group call but using different encryption methods. In the case of 8 normal conference calls the data packets are sent to all users using an encryption where 9 all participants have a copy of the decryption key. In private mode or mute mode the data packets broadcasted to the users utilize a different encryption where only select users 11 share the decryption key. Those with the key are able to participant in the call and those 12 without are excluded. The advantage of using a broadcast packet is that it requires less 13 bandwidth for last mile communication than sending separate packets demands. In yet 14 another embodiment a single packet is sent to the gateway, and the signaling server clones the packet for distribution to all participants in normal call mode and to select 16 callers in private or mute mode. 17 HyperSecure File Storage - Although the secure dynamic communication 18 network and protocol was invented and developed as a HyperSecure communication 19 system for telephony and real time data transport, the security mechanisms intrinsic to the SDNP network and protocol render it perfectly suited for HyperSecure file and data 21 storage. In its simplest description, if a HyperSecure call involves anonymous fragmented 22 data transport of scrambled encrypted data from one caller to another, i.e. end-to-end 23 communication from one SDNP client to another SDNP client, then HyperSecure file and 24 data storage can be envisioned as a communication that is stopped halfway and stored in a buffer indefinitely until recalled. Another name for Hypersecure distributed file storage 26 is Disaggregated Data Storage. 27 This simplified description, that storage is a communication that is stopped in the 28 middle of packet delivery, is technically more accurate than it may first appear. In the 29 above-referenced U.S. Application No. 14/803,869 the buffering of data packets temporarily until other packets catch up was explicitly disclosed and described 31 operationally. While buffering within the nodes of the SDNP cloud occurs in a scale of

1 milliseconds rather than months, the SDNP system has the ability to wait or hold data 2 without losing the information recovered to recover the original content. Of course, such 3 a simplified implementation lacks certain features needed for long-term file management 4 such as directories, menus, recycling of files, refreshing of security credentials and other such features. 6 An example of the data transport from a client to a fragmented data storage 7 network is shown in FIG. 81. As shown, SDNP client 1700A with an IP address IP Ci, 8 transports a series of data packets over the SDNP cloud to SDNP file storage servers 9 1700H, 1700M and 1700L with corresponding IP addresses IP F7, IP F9,1, and IP F9,4. In operation, client node Ci, sends a series of data packets 1730X with corresponding 11 headers 1726X from address IP Ci, to SDNP gateway Mo,o. Data packets 1730X are 12 exemplified by data packets 1730H, 1730L and 1730M with corresponding headers 13 1726H, 1726L and 1726M. To insure accuracy, Layer 4 transport uses TCP rather than 14 UDP. The packets include a SDNP Zip or other ID labeled tag X used to identify them for routing, in the case of data packets 1730H, 1730L and 1730M, tagl, tag 2 and tag 3. 16 The payload portion of each packet carries unique data, e.g. in a three part fragmented 17 file SDNP file 1, SDNP file 2, and SDNP file 3. Security credentials in this Last Mile use 18 zone U1 information with a corresponding preamble 1. 19 Once the data packets enter the SDNP cloud they are routed to different destinations in accordance with their identity and the instructions of a signaling server 21 (not shown). The data packet 1730H with header 1626H and tag 1 carrying SDNP file 1 22 is routed to SDNP gateway node Mo,4. SDNP gateway node Mo,4 then routes the packet 23 1730H to file storage node F7,1 using security credentials for zone U7. Meanwhile, the 24 packet 1730L with its ID as tag 2 carrying SDNP file 2 is independently routed to SDNP gateway node Mos. SDNP gateway node Mos then routes the packet 1730L to file storage 26 node F9,4 using security credentials for zone U9. 27 Nearly contemporaneously, the packet 1730M with its ID as tag 3 carrying SDNP 28 file 3 is independently also routed to SDNP gateway node Mos, not necessarily using the 29 same meshed routing path as data packet 1730L with an ID of tag 2. SDNP gateway node Mos also routes the packet 1730M with tag 3 to file storage node F9,1 also using security 31 credentials for zone U9.

1 In this manner, SDNP file 1 is delivered to file storage node F7,1 using security 2 credentials for zone U7, while SDNP file 2 and SDNP file 3 are delivered to file storage 3 nodes F9,4 F9,1respectively with both using security credentials for zone 9. Although the 4 files are owned by client node Ci, the client does not have access to the security credentials used to encode and protect the contents of the files. Since no one file storage 6 node contains all the data, and since the client owning the data does not have access to 7 the security credentials used to store the data, it is difficult for a hacker to steal the files' 8 contents because (i) they are fragmented into incongruent and unusable pieces (ii) all the 9 files use different security credentials to scramble and encrypt the data, (iii) they are stored in different locations and on different Last Mile networks and (iv) there is no way 11 to tell the various stored data comes from the same SDNP source file. Zones containing 12 the file storage servers may also be referred to as "storage side" zones to distinguish them 13 from the zone where the file owner is located, i.e. on opposite sides of the SDNP cloud. 14 By this definition, zone U1 is the SDNP client zone, also referred to the as "file owner" zone, while zones U7 and U9 are "storage-side" zones. 16 The application of the SDNP network communication protocols on file storage is 17 further illustrated is the flow chart of FIG. 82A illustrating the "write operation", the 18 general steps where a SDNP client and file owner stores, i.e. writes, their data onto 19 HyperSecure file storage servers. As shown, SDNP client 1700A splits unparsed file 1705 using SDNP splitting operation 1057 and parsing function 1052 to produce a multi 21 part file or document, in the example shown a three-part file comprising parsed files 22 1706A, 1706B, and 1706C. Optionally, the file's contents may be scrambled before 23 splitting. These three files are then transported across the SDNP network as unrelated 24 data or communiques. The steps involved in their routing across the SDNP network to their final destinations utilize the same methods disclosed herein for HyperSecure Last 26 Mile communication and previously described for meshed routing in the SDNP cloud. 27 Specifically Last Mile HyperSecure transport 1707 uses security credentials in 28 accordance with Zone Ul. HyperSecure meshed transport 1708 in the SDNP cloud 29 employs zone Z Isecurity credentials. Although, these HyperSecure data transport operations are represented as large blocks, packet transport actually occurs across a 31 network of routers, servers, and soft-switches as described in this disclosure using a

1 distributed system having no master key, no central control, and no access to packet 2 content. 3 While zone Ul Last Mile routing may involve sending the data packets over a 4 infrastructure involving a limited number of routing choices, the methods described for HyperSecure Last Mile communication, including multi-PHY last link routing, routing of 6 sequential packets to multiple SDNP gateways, and the use of dynamic source 7 addressing, i.e. changing the name of the client's IP address, are equally applicable to 8 HyperSecure file storage operations. Once the data packets reach the SDNP cloud, their 9 transport utilizes anonymous meshed routing with scrambled dynamically encrypted data preventing monitoring of the file content or even the metadata associated with the 11 communication. Ultimately, all three data packets arrive at different SDNP file storage 12 servers 1700H, 1700M, and 1700L with corresponding SDNP node names F7,, F9,1, and 13 F9,4 located in different security zones. After network transport, parsed file 1 is processed 14 in accordance with zone U7 file security operation 1709A and stored on SDNP file storage node F7,1. Parsed files 2 and 3 are processed in accordance with zone U9 file 16 security operations 1709B and 1709C and stored on SDNP file storage nodes F9,1 and 17 F9,4. In this manner, no one file contains all the data, and no single security credential can 18 unlock all the component files to recreate the original. 19 In the "read operation" of a HyperSecure stored file shown in FIG. 82B, the sequence of data transfers between the file storage servers and the SDNP client, i.e. the 21 file owner, is reversed. Reading a HyperSecure file involves undoing the process by 22 which the file was originally saved in reverse order involving (i) identifying the parsed 23 files in each storage server, (ii) removing the local storage security provisions from each 24 parsed file (iii) transporting each recovered parsed file back to the SDNP client across the SDNP cloud and HyperSecure Last Mile, (iv) collecting the parsed files from the various 26 related communiques, and (v) merging (un-splitting) and as applicable unscrambling the 27 parsed files using the client's local security credentials to recover the original file. 28 To further elaborate in the described HyperSecure file "read operation", the 29 relevant contents of file storage server 1700H saved in file storage node F7,1 is processed using Zone U7 file security operations 1709A to recover parsed file 1. Independently of 31 parsed files 2 or 3, parsed file 1 is communicated back to SDNP client node Ci, using the

1 SDNP cloud shown in simplified form by HyperSecure transport operation 1708 using 2 zone Z Isecurity credentials, and then by zone U1 Last Mile HyperSecure transport 3 operation 1707. Concurrently, the relevant contents of file storage server 1700M saved in 4 file storage node F9,1 is processed using Zone U9 file security operations 1709B to recover parsed file 2. Independently of parsed files 1 or 3, parsed file 2 is communicated 6 back to SDNP client node Ci using the SDNP cloud shown in simplified form by 7 HyperSecure transport operation 1708 using zone Z Isecurity credentials, and then by 8 zone U1 Last Mile HyperSecure transport operation 1707. Meanwhile, the relevant 9 contents of file storage server 1700L saved in file storage node F9,4 is processed using Zone U9 file security operations 1709C to recover parsed file 3. Independently of parsed 11 files 1 or 2, parsed file 3 is communicated back to SDNP client node Ci, using the SDNP 12 cloud shown in simplified form by HyperSecure transport operation 1708 using zone ZI 13 security credentials, and then by zone U1 Last Mile HyperSecure transport operation 14 1707. The independent packet routing of the three constituent parsed files during the 16 read operation is exemplified in FIG. 83, where server node 1700H sends data packet 17 1731H carrying SDNP file 1 and with ID "tag 7" using TCP transport from file storage 18 address IP F7,1 to SDNP gateway server at address IP Mo,4. Packet 1731H includes header 19 1727H containing preamble 7 and other information that in tri-channel communication was provided previously in a command and control packet delivered by the signaling 21 server. 22 Meanwhile, server node 1700L sends data packet 173IL carrying SDNP file 2 23 and with ID "tag 9" using TCP transport from file storage address IP F9,4 to SDNP 24 gateway server at address IP Mos. Packet 1731L includes header 1727L containing preamble 9 and other information that in tri-channel communication was provided 26 previously in a command and control packet delivered by the signaling server. 27 Independently and concurrently server node 1700M sends data packet 173IM carrying 28 SDNP file 3 and with ID "tag 8" using TCP transport from file storage address IP F9,1 to 29 SDNP gateway server also at address IP Mos. Packet 173IM includes header 1727M containing preamble 9 and other 31 information provided in tri-channel communication previously using a command and

1 control packet delivered by the signaling server. The three data packets 1731H, 1731L, 2 and 173IM traverse the SDNP cloud using zone Z Isecurity credentials till they finally 3 emerge from SDNP gateway Mo,o hosted by SDNP cloud server 1701U where the data 4 packets are sequentially sent by successive data packets 1731X using corresponding zone headers 1727X and zone U1 security credentials to client device 1700A at address IP Ci. 6 Referring again to FIG. 82B, after the three parsed files 1, 2, and 3, namely 7 1706A, 1706B and 1706C are delivered to SDNP client device 1700A using independent 8 routing, they are merged into a single unparsed file 1705 using mixing operation 1061 9 and as applicable followed by an unscrambling operation (not shown) performed in accordance with zone U1 security credentials. 11 Rather than adding extra file server operations to secure stored data, the security 12 operations 1709A, 1709B and 1709C actually comprise Last Mile HyperSecure 13 communication between the SDNP cloud and the corresponding storage-servers 1700H, 14 1700M, and 1700L. As an artifact of Layer 3 network connectivity using the SDNP communication protocol, SDNP file storage is intrinsically HyperSecure, comprising 16 scrambled, fragmented, encrypted data stored across distributed nonvolatile data drives 17 including the use of data deception methods such as junk data insertions and junk files. 18 Aside from the foregoing data security methods, HyperSecure storage as disclosed herein 19 utilizes anonymous file names lacking any meaningful metadata, traceability to the file owner, routing by which the file was delivered, or the identity of any other file storage 21 server holding missing components from the original source file. 22 Despite the interoperability on the SDNP network, the physical realization of the 23 storage servers, i.e. their Layer 1 PHY implementation and Layer 2 transport, protocols 24 may vary substantially without impacting storage functionality, access times, or global accessibility. FIG. 84A illustrates by example, physical realization of SDNP file storage 26 servers including the topmost drawing showing SDNP gateway 1701B connected to 27 SDNP file storage server 1740A via router 27. For higher network performance and 28 further resiliency to attack, the middle illustration shows a direct connection between 29 SDNP gateway 1701B and SDNP file storage server 1740A using optical fiber 91 with no intervening routers. As shown in the bottom example, the file storage server may 31 comprise a larger memory array with a server controller 1740B and the storage drives

1 1740C and 1740D. The drives may comprise any media including hard disk drive or flash 2 drive based nonvolatile memory. To further limit access, the SDNP gateway and the 3 SDNP file storage server may be physically located in the same location and facility with 4 only a fiber link connecting them. They may even share a common room, e.g. physically locked in a vault, with strictly managed access control and surveillance monitoring of 6 anyone entering the facility. 7 FIG. 84B further illustrates than some portion of the fragmented data file may be 8 stored locally at the site of the file owner. As shown, the file owner's desktop 36 may 9 store a distributed file across several devices including (i) local file storage server 1740A accessed over WiFi router 1352, which is connected to SDNP gateway node Mo,o on 11 server 1701A, (ii) file storage server 1740B connected to SDNP gateway node Mo,4, and 12 (iii) file storage server 1740C connected to SDNP gateway node Mos. Because the data is 13 fragmented as saved across distributed drives 1740A, 1740B, and 1740C, other devices 14 including notebook 35, tablet 33, and cell phone 29 do not have access to the saved file even though local file server 1740A and file owner desktop 36 share the same WiFi 1352. 16 The process of storing each parsed portion of a file uniquely into separate file 17 storage servers, referred to non-redundant HyperSecure file mapping, is illustrated in 18 FIG. 85A. As shown, client device 1700A comprising SDNP client node Ci, stores 19 parsed file 1706A exclusively in file storage server 1700H, parsed file 1706B exclusively in file storage server 1700M, and parsed file 1706C exclusively in file storage server 21 1700L, corresponding to a one-to-one file mapping between parsed files 1, 2, and 3 with 22 storage nodes F7,, F9,1, and F9,4, respectively. Delivery of the files utilizes HyperSecure 23 Last Mile communication, securing the transfer of the data as well as its storage. One 24 disadvantage of non-redundant file mapping is that the loss of any one of the file storage servers, either temporarily or permanently, jeopardizes file access and recovery. In the 26 context of this application, the terms "resilience" and "resilient" are used to define 27 guaranteed and timely access to stored data, i.e. the confidence that stored data is not lost 28 or its access is impaired for a substantial durations. By this token, the non-redundant 29 HyperSecure file mapping shown exhibits poor resilience because a single point failure prevents file access. Poor resilience can be overcome by a redundant system, one where 31 the same data is saved in more than one file storage server,

1 Another metric describing or rating the data storage system's resiliency is a metric 2 defined herein as read redundancy factor RRF, a term defining the number of backup 3 systems providing data access in case the primary data storage is unavailable. In the 4 example shown, there is one location for each unique piece of data. This results in a read redundancy factor of zero, or mathematically RRF = 0, meaning that a single point 6 connection or file server failure may result in temporary or permanent data loss because 7 the file cannot be read by the file owner. 8 An alternative file mapping with a read redundancy factor of RRF = 1 is shown in 9 FIG. 85B. In this example, parsed file 1 is stored on file storage server nodes F9,4 and F7,1, parsed file 2 is stored on file storage server nodes F9,1 and F7,, and parsed file 3 is 11 stored on file storage server nodes F9,4 and F9,1. In such an implementation, if file storage 12 server node F9,1 became impaired or unavailable, parsed file 3 could still be accessed 13 from file storage server node F9,4 and parsed file 2 could still be accessed from file 14 storage server node F7,1. As such, any single storage node failure will not prevent read access to the HyperSecure file. FIG. 85C illustrates HyperSecure File mapping with a 16 RRF = 2 . The file mapping retains file storage servers 1700L, 1700M, and 1700H but 17 adds a second set of file storage servers 1700J, 1700E, and 1700F for realizing file 18 storage server nodes Fs,2, F4,4, and F6,s, respectively. As such, file storage server 1700J 19 acts as a backup for file storage server 1700L, file storage server 1700E acts as a backup for file storage server 1700M, and file storage server 1700F acts as a backup for file 21 storage server 1700H. Although the examples shown comprise a file parsed into 3 22 sections, it is understood that a document may be parsed into a greater number of sections 23 if desired. To insure HyperSecure storage, the original file should never be parsed into 24 fewer than two and ideally no fewer than three sections. To illustrate the process by which redundant files are stored and read using 26 HyperSecure file storage, it is beneficial to illustrate the transactional sequence of 27 communiques and file transfer functions overlaid atop the SDNP network used to 28 facilitate the storage process. The network shown in FIG. 86, for example, includes client 29 device 1700A implementing client node Ci, router 1702G, signaling server 1715 implementing SDNP node S, name server 1714 implementing SDNP node NS, cloud 31 servers 1701U implementing SDNP cloud nodes Mo,o, Mo,4, and Mos, and SDNP file

1 storage servers 1700H, 1700L, and 1700M realizing SDNP file storage nodes F7,, F9,4 2 and F9,1 respectively. 3 In FIG. 87A client device 1700A at address "IP Cii" makes a file write request to 4 signaling server 1715 at address "IP S' by means of data packet 1710A including C&C payload 1711A, in turn comprising a description of the file size and requested level of 6 security and redundancy. In FIG. 87B signaling server 1715 sends data packet 1710B to 7 name server 1714 requesting the IP or SDNP addresses of the file storage server nodes 8 F7,, F9,4 and F9,1. The selection of the file address server nodes to be used can be chosen 9 randomly from a list of storage nodes, or selected based geographically on one node available near the client or on those in disaster free regions. Selection may also be based 11 on a performance parameter such as unused memory capacity of the node, propagation 12 time to the file storage node, uptime reliability rating of the node, or other such 13 considerations. In FIG. 87C name server 1714 sends signaling server 1715 data packet 14 1710C containing the IP or SDNP addresses of the file storage server nodes F7,, F9,4 and F9,1. The signaling server 1715 then calculates Last Mile and meshed cloud delivery of 16 the parsed files to the file storage servers 1700H, 1700L and 1700M. 17 In FIG. 87D, signaling server 1715 sends data packet 1710D to client device 18 1700A, the packet being routed from address "IP S" to "IP Ci" through router 1702G. 19 Data packet 171ID contains C&C payload 171ID containing Last Mile routing for the impending file transfer in zone Ul, the client zone, specifically routing multiple packets 21 from address "IP Cii" to SDNP gateway at "IP Mo,o" with tag 1, tag 2 and tag 3 22 identification of each packet (labeled as "tag X" for simplicity). Concurrently, signaling 23 server 1715 also sends data packet 1710E to SDNP gateway 1701U, the packet being 24 routed from address "IP S" to "IP Mo,o". This packet includes C&C payload 1711E showing SDNP cloud routing using zone Z Isecurity credentials for a packet with ID tag 26 X, in this case from SDNP gateway address "SDNP Mo,o" to the next node in the cloud, 27 e.g. at address "SDNP Mo,5" (not shown). In accordance with the Secure Dynamic 28 Communication Network and Protocol, the routing of data packets throughout the SDNP 29 cloud using meshed anonymous fragmented transport is dynamically selected based on the current condition of the real time network. Specifically, routing within the SDNP 31 cloud of real time data packets arriving at any SDNP gateway depends on node-to-node

1 propagation delays within the SDNP cloud and on the urgency of each real time data 2 packet assigned by the signaling servers. 3 In FIG. 87E, signaling server 1715 sends C&C data packets to the Last Mile 4 nodes located on the storage side, i.e. to zones U7 and U9. As shown, data packet 1710F is sent to SDNP gateway Mo,4, the packet being routed from address "IP S" to "IP Mo,4" 6 containing C&C payload 171IF communicating that a data packet with tag 1 should be 7 anticipated by gateway node Mo,4 and, when received, forwarded onto Last Mile address 8 "IP F7,1". A second data packet 1710G is forwarded from the signaling server 1715 to file 9 storage server 1700H at address "IP F7,1". The C&C payload for storage in zone U7 defines the incoming packet with ID tag 1 from source address "IP Mo,4" but because the 11 function of the node is storage and not communication the destination field is left blank, 12 i.e. filled with a null value. Once the command and control data packets are distributed to 13 the network, the file transfer can ensue. 14 FIG. 88 illustrates the fragmented data transport during file HyperSecure storage where client device 1700A sends a series of data packets 1712X carrying SDNP data files 16 1, 2, and 3 from address "IP Cii" to the SDNP gateway at address "IP Mo,o" using TCP 17 data transport. Each data packet has a unique identifier ID, namely tag 1, tag 2, and tag 3. 18 These files are then transported through the SDNP cloud to other gateways, namely 19 SDNP gateway nodes Mo,4 and Mos. The packet containing SDNP data 1 arriving at gateway node Mo,4 is transported in data packet 1712A from address "IP Mo,4" to "IP 21 F7,i" using TCP with zone U7 security credentials, while data 2 and data 3 packets 22 arriving at gateway node Mo,s are transported with zone U9 security credentials in data 23 packets 1712B and 1712C from address "IP Mos" to addresses "IP F9,4" and "IP F9,i" 24 respectively. Storage may also include local encryption in the file server to prevent data scanning of the drive. This encryption process is local and is not related to the SDNP 26 security provisions. The data packets' content SDNP data 1, SDNP data 2, and SDNP 3 27 contain the actual fragmented files being stored. 28 The preamble in each data packet, e.g. preamble 1 in data packet 1712A, may also 29 contain an encryption key supplied by the client as part of a symmetric key encryption operation. Using symmetric key encryption, the SDNP client node Ci, generates a split 31 key, one for encryption and its complement for decryption. The symmetric encryption

1 key is then supplied to the file storage server node F7, delivered by data packet 1712A in 2 this example. In the future, whenever the client requests to read or access the contents of 3 the stored file, file storage server node F7, encrypts the requested file using this 4 encryption key before sending the file back to the client. Because only the client possesses the associated decryption key, only the client can open the read file. While this 6 method provides an extra layer of protection, it has the disadvantage that only a single 7 client can access the file as a read operation, preventing the use of multiple client file 8 "owners" needed to facilitate redundant access in the case the original client device is 9 stolen, damaged, or lost. Around the time of the data transfer and file storage process, the signaling server 11 1715 also sends instructions to file storage servers 1700H, 1700L and 1700M regarding 12 "link reply" message routing. A link reply is a data packet and C&C payload confirming 13 to the client that the write operation was successful and storage of each parsed file is 14 complete. These messages are sent to the client file-owner independently from each file storage server involved in storing the transferred parsed files. The file servers send their 16 write-confirmation replies to the client independently with no knowledge of one another, 17 and the write-communication replies are transmitted using independent security 18 credentials including unique states different than the states operative at the time of the 19 write operation. Routing of these link reply messages does not necessarily utilize a reverse direction of the same routing path as those used to transfer the files. Such a reply 21 could potentially be used by cyber-attackers as a trace back to find a file's owner. 22 Instead, the link reply utilizes a packet ID to identify to the client that the stored files are 23 part of the same file and stored as part of the same fragmented write-operation. 24 In operation, the signaling server sends routing for the link reply messages to the file storage servers, to the client file-owner, and to all the intermediate SDNP nodes 26 involved in the link-reply message routing. The signaling server 1715 coordinates the 27 link reply message routing as shown by example in FIG. 89A using data packets 28 containing command and control payloads, e.g. file storage server 1700H receives data 29 packet 1721G containing C&C payload 1722G containing header data for "link 1 reply" routing from address IP F7,1 to address IP Mo,4. SDNP gateway node Mo,4 receives data 31 packet 1712F containing C&C payload 1722F describing routing of the tag 1 data packet

1 from address "SDNP Mo,4" to another node within the SDNP cloud (not shown), in this 2 case at address "SDNP Mo,14". Similarly, signaling server 1715 sends file storage server 3 1700M data packet 1721M containing "link 3 reply" tag 3 packet Last Mile routing 4 instructions from address "IP F,i" to "IP Mos". While the storage-side Last Mile routing for file data packets and their corresponding link reply messages may be identical or 6 similar, routing of the reply messages through the SDNP cloud are most likely dissimilar 7 due to the dynamic nature of the SDNP cloud. 8 The actual routing of the link reply messages from participating file storage server 9 nodes is shown in FIG. 89B. As shown, file storage server 1700H replies with data packet 1720A identified by tag 1 and carrying a payload "FS link 1". The packet is routed 11 from address "IP F7,1" to SDNP gateway at address "IP Mo,4" using zone U7 security 12 credentials. From the SDNP gateway, the tag 1 data packet is routed through the SDNP 13 cloud to client side gateway at address "SDNP Mo,o" where the address is converted to 14 Last Mile data packet 1720X and routed from address "IP Mo,o" to address "IP Ci" using TCP transport using zone U1 security credentials, and carrying tag 1 data, namely 16 preamble 1 and FS link 1. 17 In a similar manner, file storage server 1700L replies with data packet 1720B 18 identified by tag 2 and carrying a payload "FS link 2". The packet is routed from address 19 "IP F9,4" to SDNP gateway at address "IP Mos" using zone U9 security credentials. From the SDNP gateway, the tag 2 identified data packet is routed through the SDNP cloud 21 (routing not shown) to client side gateway at address "SDNP Mo,o" where the address is 22 converted to Last Mile data packet 1720X and routed from address "IP Mo,o" to address 23 "IP Cii" using TCP transport using zone U1 security credentials, and carrying tag 2 data, 24 namely preamble 2 and FS link 2. The third piece of the parsed file identified by tag 3 and carrying a payload "FS 26 link 3" is sent from file storage server 1700M via data packet 1720C. This tag 3 packet is 27 routed from address "IP F9,i" to SDNP gateway at address "IP Mos" using zone U9 28 security credentials. From the SDNP gateway, the tag 3 identified data packet is routed 29 through the SDNP cloud to client side gateway at address "SDNP Mo,o" where the address is converted to Last Mile data packet 1720X and routed from address "IP Mo,o" to

1 address "IP Cii" using TCP transport using zone U1 security credentials, and carrying 2 tag 3 data, namely preamble 3 and FS link 3. 3 FIG. 89C illustrates an example of content of FS link data packet 1720A routed 4 from file storage server 1700H back to the client and file owner. As shown, the data packet comprises Last Mile routing from address "IP F7,i" toSDNP gateway at address 6 "IP Mo,4" using TCP in a packet with ID tag 1 created in security zone U7. Reply 7 preamble 1719A contains a description of the data payload 1741A and also contains 8 optional security credentials used to execute or enhance the security of the FS link data 9 packet 1720A being delivered to the client. In tri-channel communication, however, the reply security credentials contained within reply preamble 1719A are generally not 11 required and unrelated to that used by the client to subsequently access and open the 12 HyperSecure stored file. Access credentials needed to create a link from the client to the 13 file stored in file storage node F7, are instead contained within data field 1741A 14 including • A unique network tag, SDNP address, or pseudo-address needed to 16 identify the file storage server where that portion of the fragmented file is stored. 17 • A description of the zone defining the security credentials used to encode 18 the file in the "storage-side" security zone (not the client's zone). 19 • Seed 1 which may contain a numeric seed or the time or state 920 used during the file's encoding prior to storage. 21 • Seed 2 which may contain a numeric seed 929 used to execute file 22 encoding as part of the storage operation. 23 • Key 1 containing a decryption key 1030 for decrypting the zone U7 24 "storage side" encryption. This key may be used in conjunction with shared secrets held in a DMZ server operating as part of the file storage server, or may represent a 26 partial decryption key that can only be operated in conjunction with another security 27 credential such as a numeric seed. 28 • Key 2 containing an encryption key 1022 sent to the client and used for 29 sending secure instructions from the client to the file storage server using symmetric key encryption.

1 • A file name or other information used to help a client identify the stored 2 file without revealing how it is stored. 3 The foregoing data packet is used for illustrative purposes and should not be 4 viewed as limiting the data packet's contents to the precise elements or format as shown in the example. The FS links 1720X received by SDNP client node Ci, once received 6 from the file storage servers participating in storing the fragmented file, are then 7 processed to create a file link for the client's device. As illustrated in FIG. 89D, this 8 operation combines FS links 1741A, 1741B, and 1741C using mix operation 1753 to 9 create an FS link aggregate "file storage read link" 1754. The file storage link 1754 is posted on the client's HyperSecure text messenger or file management system for easy 11 single-pushbutton recall of the HyperSecure file. HyperSecure operations are invisible to 12 the user. The file owner need not be concerned with the fact that the file is actually 13 fragmented, encoded, and stored across a distributed file storage system. File recall 14 appears as if the file were resident locally. The FS link therefore is a key element to accessing any file stored across a distributed file storage system. 16 A simplified representation of the FS Link communication is shown in FIG. 90A 17 where all three file storage servers send their respective FS links to client node Ci, and 18 corresponding client device 1700A, specifically file storage server 1700H sends FS link 19 1, file storage server 1700M sends FS link 2, and file storage server 1700L sends FS link 3. Within client device 1700A, the SDNP app software in client node Ci, combines the 21 three incoming FS links 1, 2, and 3 to form a link to the stored file. This combined link 22 appears in the SDNP messenger as a file storage confirmation. In non-redundant file 23 management, the FS link information is sent only to the client device. For user file 24 management, the file link can be named either at the time the file storage was requested or upon receiving the confirmation message. 26 Since the file storage link is sent to the client directly from the file storage servers 27 and not through a signaling server, only the client with the link has access to the file. This 28 FS link is required to recall and read the fragmented file. Without the FS link, the stored 29 file and its contents will be lost forever and become irreversibly irretrievable. To reduce the risk that the FS link may be lost, an alternative approach sends the FS link to two 31 client devices - the client device and an auxiliary device. The auxiliary device may be a

1 second device owned by the client or in business cases, a second device owned by the 2 company. Alternatively, the second device may comprise another server with its own 3 login security and user identity verification. 4 Redundant link access to fragmented distributed stored files made in accordance with this invention may applied to both read redundant, i.e. RRF > 1, and non-redundant 6 file storage systems. The use of a redundant link in a HyperSecure distributed memory 7 system lacking read redundancy (RRF = 0) is illustrated in FIG. 90B. In such as system, 8 file mapping between parsed files 1706A, 1706B, and 1706C and corresponding file 9 storage servers 1700H, 1700M, and 1700L is non-redundant. As shown, the FS links 1, 2, and 3 are sent to two client devices, namely 1700A hosting SDNP client node Ci, and 11 auxiliary client device 1700B hosting a backup client nodeC2,1. In the event that one of 12 the FS links is lost or becomes unavailable for any reason, the FS link on backup client 13 can be used for file recovery. In this regard, the SDNP distributed storage system 14 describes a non-redundant read implementation with single link redundancy, i.e. RRF = 0 and LRF = 1. 16 An example of HyperSecure memory comprising both read and link redundancy 17 is shown in FIG. 90C, where parsed files 1, 2, and 3 are each mapped to two file storage 18 servers, i.e. to realize a read redundancy factor RRF = 1, and with each FS link sent to 19 two clients to achieve a link redundancy factor LRF = 1. The immunity of the storage system to both read and link related failures means the system can be considered as a true 21 redundant HyperSecure file management system with an overall storage redundancy 22 factor SRF = 1. We herein define the storage redundancy factor SRF as a redundancy 23 factor equal to the lowest of RRF and LRF. For example, if RRF = 0 and LRF = 1, the 24 SRF = 0. If instead RRF = 3 and LRF = 2, then the overall storage redundancy is SRF= 2. In order to implement an overall system SRF = 3, each parsed file must be stored in 26 four separate file storage servers (such as shown previously in FIG. 85C) and the FS 27 links must be sent to four separate clients. 28 As such, the overall storage redundancy factor SRF is a direct measure of the 29 resiliency of the distributed storage system from failure. This principle is summarized in the graph of FIG. 91 where the abscissa describes the # of file storage servers used in a 31 file storage system and the ordinate describes the number of FS links sent to separate

1 clients. As shown, a single file storage server has no redundancy, i.e. RRF = 0. Increasing 2 the number of file storage devices improves the read redundancy but has no affect on the 3 link redundancy. Conversely, sending a link to a single client offers no link redundancy, 4 i.e. LRF = 0 regardless of the number of available file storage servers. In either case, i.e. for one storage server or one client link, the overall storage redundancy factor SRF = 0, 6 meaning the file storage system has no resiliency as shown graphically by the L shaped 7 region. 8 As shown, storing a three part parsed file on 3 file storage servers as shown 9 previously results in a read redundancy factor RRF = 1. Provided at least two clients receive the FS link, the link redundancy of LRF > 1 is achieved. The combination of 11 either LRF = 1 or RRF = 1 produces L-shaped region 1724B where SRF = 1, i.e. 12 providing some degree of system resiliency. Note that even when 6 servers are employed, 13 if the FS links are sent to only two clients the system still exhibits only a limited degree 14 of resiliency, i.e. SRF = 1. By sending the FS links to 3 clients and storing data redundantly on 6 storage 16 servers, region 1724C defines the conditions where SRF = 2 offering a fairly robust 17 degree of storage resiliency. Region 1724D illustrates a further enhancement in 18 resiliency where SRF = 3 using six file storage servers and 4 clients receiving keys. So 19 the bottommost row and leftmost column have the lowest storage resiliency and the upper right hand corner has the best storage resiliency. 21 HyperSecure distributed file storage made in accordance with this disclosure 22 achieves long-term sustainable security by adapting, i.e. re-purposing, numerous 23 inventive elements from SDNP communication. These inventive elements include: 24 • Parsing a file and distributing its fragmented content across a number of un-related network connected file storage servers, 26 • Transporting files between client and file storage servers using 27 end-to-end HyperSecure communication comprising SDNP dynamically 28 scrambled encrypted anonymous fragmented data transport with no master key, 29 • Storing the fragmented files in file storage servers in a manner where the storage servers lack access to client security credentials used to initially 31 fragment and encode the stored data, i.e. where the file storage server does not

1 possess the "client side" Last Mile security credentials required to decode, access, 2 or read the file, 3 • Optionally encoding fragmented files in storage servers in a 4 manner where a client (file owner) lacks the security credentials need to decode the stored data except through a secure link, i.e. where the "client-side" Last Mile 6 does not possess the "storage side" Last Mile security credentials used to locally 7 encode the files, 8 • Limiting the number of file storage links needed to locate and open 9 the file and restricting user access to such links to the file owner's client device along with any redundant or backup devices, 11 • Requiring client multi-factor authentication and identity 12 verification in order to execute a file link and invoke a read or erase operation, 13 • Utilizing anonymous data packet routing and anonymous file 14 names whereby use of the file link for data recall provides reveals no information as to the location or encoding of the HyperSecure file storage and where, with 16 exception of the file link, no routing information is stored in the SDNP network or 17 HyperSecure file storage system, 18 • Distributing a fragmented file across a number of storage servers 19 using undisclosed file server locations, and except through the file storage link, using anonymous identities unknown to the client, the SDNP network, or to other 21 storage servers, 22 • Employing tri-channel communication where the SDNP signaling 23 servers used to plan file routing for distributed storage have no access to the 24 content of the fragmented files or the security credentials used to encode the files and where the SDNP media nodes used to transport the file content utilize single 26 hop SDNP data packets lacking the identity or address of the client or the file 27 storage server, 28 • Employing dynamic file renaming and data relocation at regular 29 intervals and after repeated file access, regenerating encoding a security credentials at the time of the file rewrite operation, and

1 • Locally encrypting the file storage server directory to thwart file 2 analysis. 3 4 Using the foregoing, the lack of any discernable file identity; the use of fragmented file distributed across a network (possibly on a global scale); and the use of 6 zone-specific security credentials renders access to and reconstruction of a HyperSecure 7 stored file inconceivable without access to file storage link. Such FS links, limited in 8 number and distributed only through the SDNP communication system, are further 9 secured by identity verification. The execution of the foregoing features for HyperSecure file storage can be 11 represented schematically in the same manner as HyperSecure communication using the 12 functional symbols shown previously in FIG. 9A. For the sake of simplicity, as shown in 13 the upper illustration of FIG. 92, any combination of scrambling 926, junk data insertion 14 1053, parsing 1052 and splitting 1057 and encryption 1026 using state or time 926C can be represented as a SDNP encode function 1750. Similarly, the decode function 1751 16 comprises decryption 1032, mixing 1061, junk data removal 1053B and unscrambling 17 928 using state or time 926B. 18 Using the aforementioned security functions, the top illustration of FIG. 93A 19 illustrates the process of distributed file storage with client side encoding. As shown, file 1705 is parsed 1052 and split 1057 to create parsed file 1706 within client device 1700A 21 used to realize SDNP client Ci. The resulting fragmented files are then encoded using 22 zone Ul security credentials by SDNP encode operation 1750B for Last Mile 23 communication performed in accordance with the methods disclosed in this application. 24 The file fragments delivered in serial or multi-route Last Mile communication are then received by SDNP gateway Mo,o and decoded using SDNP decode operation 1751C in 26 accordance with zone Ul security credentials recovering the parsed file 1706. The parsed 27 filed 1706 is then re-encoded by SDNP encode operation 1750C in accordance with 28 SDNP cloud zone Z1 security credentials. During meshed transport, after a series of zone 29 Z1 decoding and encoding operations in the SDNP cloud (not shown), the final data packets arrive at their respective SDNP gateways including, by example, gateway Mo,s 31 where SDNP decode operation 1751D recovers parsed file 1706, then re-encodes it using

1 SDNP encode operation 1750D in accordance with zone U9 security credentials. In the 2 example shown, parsed file 1706 is then fragmented (split) into two files, and the 3 fragmented files 2 and 3 of parsed file 1706 are then recovered using SDNP decode 4 function 1751E and stored in files storage servers 1740B and 1740C, respectively. In this method, the data files stored in the file storage servers are fragmented but otherwise 6 (except for local drive encryption) the files are accessible by cyberattack of the drive 7 data. As such, security is achieved by the file fragmentation and distributed storage. 8 A greater degree of file security is achieved by using the process shown in the 9 lower illustration of FIG. 93A, which illustrates the process of distributed file storage with full client side encoding. As shown, file 1705 is processed by SDNP encode 11 operation 1750A to create scrambled, encrypted, parsed file 1706 within client device 12 1700A used to realize SDNP client Ci. Operation 1750A also includes splitting file 13 1706 in three fragmented files 1, 2 and 3. The fragmented files 1, 2, and 3 are then 14 encoded using zone U1 security credentials by SDNP encode operation 1750B for Last Mile communication performed in accordance with the methods disclosed in this 16 application. The file fragments delivered in serial or multi-route Last Mile 17 communication are then received by SDNP gateway Mo,o and decoded using SDNP 18 decode operation 1751C in accordance with zone U1 security credentials recovering the 19 scrambled, encrypted, parsed file 1706. Parsed file 1706 is then re-encoded by SDNP encode operation 1750C in accordance with SDNP cloud zone ZI security credentials. 21 During meshed transport, after a series of zone Z1 decoding and encoding 22 operations in the SDNP cloud (not shown), the final data packets arrive at their respective 23 SDNP gateways including, for example, gateway Mo,s where SDNP decode operation 24 1751D recovers scrambled, encrypted, parsed file 1706, then re-encodes it using SDNP encode operation 1750D in accordance with zone U9 security credentials. The 26 fragmented files 2 and 3 of scrambled, encrypted, parsed file 1706 are then recovered 27 using SDNP decode function 1751E and stored respectively in file storage servers 1740B 28 and 1740C. The file is therefore secured not only by fragmented distributed storage, but 29 by some combination of scrambling, junk data, and encryption known only to the client's security zone. In a similar manner file 1 is transported through the SDNP cloud to

1 gateway Mo,4where it is stored in file storage 1700H in zone U7 as shown for packet 2 1712A in FIG. 88. 3 In both examples described, a greater degree of security can be achieved by 4 eliminating the final SDNP decode operation 1751E shown in the illustrations of FIG. 93B. In this manner, the files stored on the file storage servers remain encoded by SDNP 6 encode operation 1750D using zone U9 security credentials. In the upper illustration the 7 files are fragmented by the client but encoded in accordance with storage side security 8 credentials for zone U9. In the lower illustration, the files are encoded in accordance with 9 client side security credentials U1 and then encoded a second time in accordance with storage side security credentials for zone U9. Such a double encoded file, aside from 11 being secured by fragmented distributed file storage, represents nested HyperSecure 12 storage because the file encoded by zone U9 security credentials contains a file encoded 13 by U1 security credentials. The advantage of nested security as disclosed is that neither 14 the client nor the storage server has the necessary information to open the stored file. A summary of exemplary methods of implementing HyperSecure disaggregated 16 file storage is shown in FIG. 94. In the examples shown, encoding and decoding used for 17 HyperSecure communication and SDNP cloud routing are removed revealing only the net 18 effect of file encoding. The upper left corner reveals the case for client zone 19 fragmentation, where the document is fragmented in accordance with zone U1 security credentials but without any additional security provisions imposed by the network's 21 storage side. The lower left corner reveals the case for client zone encoding, where the 22 document is encoded by operation 1750B, i.e. scrambled, junked, fragmented, and 23 encrypted in accordance with zone U1 security credentials but without introducing any 24 security provisions on the network's storage side. The upper right corner reveals the case for client zone U1 fragmentation, but 26 where the extra step of SDNP encoding, i.e. scrambling, junk insertions, fragmentation, 27 and encryption, is introduced on the storage side in accordance with zone U9. The lower 28 right corner represents an example of full nested HyperSecure file storage where the file 29 is encoded and fragmented in accordance by SDNP encode operation 1750B with the zone U1 client side security credentials, and then the file is encoded a second time in 31 accordance with the zone U9 security credentials of the storage side Last Mile.

1 To recall and read the file, data recall must utilize security operations comprising 2 anti-functions executed in the precise reverse order of the encoding, as illustrated in FIG. 3 95. In the upper left hand case to recall client zone fragmented data, the parsed file 1706 4 recalled from different file storage servers is recombined using merge operation 1061 to recover original file 1705. In the lower left hand case recalling client zone encoded data, 6 parsed file 1706 recalled from different file storage servers is recovered to access original 7 file 1705 using SDNP decode operation 1751H, the exact anti-function of splitting 8 operation 1750B comprising mixing, decryption, unscrambling. In the upper right hand 9 case of storage zone encoded, client zone fragmented files, the inverse operation comprises first performing SDNP decode operation 175IF to undo the effects of zone U9 11 security operations to recover parsed file 1706, followed by file merge operation 1061 to 12 cancel the effect of file splitting operation 1057 made in accordance with zone ZI 13 security credentials. 14 In the lower right hand example to read a fully-nested HyperSecure file, data stored on different file storage servers is decoded by SDNP decode operation 175ID 16 using zone U9 security credentials to reconstitute file 1706, a multipart file still 17 scrambled, junked, parsed, and encrypted in accordance with zone Z Isecurity 18 credentials. Zone Z Ispecific SDNP decode operation 1751H then performs the 19 sequential anti-functions of encoder 1750B, an operation comprising mixing, decryption, unscrambling to recall original file 1705-The operation of executing a sequential anti 21 function to recover a file should occur in the inverse order of the sequence used to create 22 it. For example, if encoding involves splitting, then scrambling, and then encrypting, the 23 inverse or anti-function, i.e. decoding, should comprise the operational sequence of 24 decrypting, then unscrambling, and then mixing. If, however, encoding sequentially involves scrambling, then encrypting, and then splitting a packet, then the inverse or anti 26 function, i.e. decoding, should comprise the sequence of mixing, then decrypting and 27 finally unscrambling the data packets 28 To invoke a file recall or "file read operation" the client invokes the aggregated 29 file link by clicking on the "file storage read link" to initiate the steps needed to recall and read a file stored on the system's HyperSecure file storage system. The read process 31 involves the following steps as illustrated in FIG. 96A:

1 • File owner and client 1700A or authorized user clicks on the "file storage 2 read link" in a SDNP application such as a SDNP enabled HyperSecure messenger 3 1196, file manager, or other SDNP enabled interface. 4 • Using a dialog interface 1765 or optionally a command line instruction, client 1700A specifies their file request 1761, including readfile, edit file (make a 6 copy of the file with write privileges), erase file (delete), refresh link (reissue security 7 credentials), or redistributefile (move the file fragments to different file storage 8 servers and issue a new file storage read link to the file owner client or clients). 9 • In "verify clients" operation 1762, SDNP signaling server 1715 confirms the identity of the client or clients requesting the file (authentication). Using dialog 11 box 1767, the client must confirm their identity using a PIN and optionally a second 12 factor such detecting a device or security token. Alternatively, a SMS text may be 13 sent to another device owned by the same client. In files requiring access approval by 14 multiple clients, the identity of every user must be verified (multi-authentication). • In the "verify privileges" operation 1763, signaling server 1715 confirms 16 the requesting client 1700A is authorized for access to the requested file with read or 17 read/erase privileges (authorization). The result is displayed in dialog box 1768 18 before confirming whether the user still wishes to download or read the file. If the 19 identity is not confirmed, the requestor may be instructed to try again. After a specified number of failed attempts, the file administrator 1700Z (if there is one) will 21 be informed of the failed attempts, and the account locked. The dialog box may 22 inform the user of the problem asking them to contact the file administrator or 23 alternatively, if hacking is suspected, the box may go blank or even throw the user out 24 of the SDNP application altogether. • In document request administration operation 1764, the SDNP signaling 26 server 1715 informs the file storage administrator 1700Z about the file access request 27 and the nature of the request (administration). This administrative step may (i) be 28 skipped altogether, (ii) log the file access request in the file storage administrator's 29 account, (iii) send a message to the file storage administrator immediately informing them of the attempted file access, or (iv) require the file storage administrator's

1 approval through dialog box 1769 before the client requesting the file is granted 2 access. 3 After these authentication, authorization, and administration (AAA) steps, upon 4 approval, the client makes a request to access the file using the steps illustrated in the flow chart shown in FIG. 96B, shown here used for illustrative purposes as a read 6 request. These steps involve the following: 7 • In read request operation 1770, the requesting client 1700A sends a file 8 read request to the SDNP signaling server 1715. 9 • In storage server name request operation 1771, the SDNP signaling server 1715 sends a file storage server name request to the SDNP name server 1714 11 requesting the current SDNP addresses of the related file storage servers, e.g. file 12 storage server 1700M. In accordance wit the SDNP method, the SDNP address for 13 SDNP clients (including file servers) changes at least once daily to prevent long-term 14 client traceability. • In storage name delivery operation 1772, the SDNP name server 1714 16 delivers the requested file names "FS addresses" to the SDNP signaling server 1715 17 whereby the SDNP signaling server maps out the file recall routing. 18 • In routing instruction operation 1773, the SDNP signaling server sends file 19 routing instructions to the client 1700A, to nodes in the SDNP cloud such as server 1700U, and to file storage servers with zone specific security credentials such as file 21 storage server 1700M with zone U9 security credentials including state or time 920, 22 numeric seed 923, decryption key 1030, and optional encryption key 1022 (used in 23 symmetric key encrypted communication). 24 • In local file recovery operation 1774, utilizing applicable security credentials including state or time information specific to the file's creation, the DMZ 26 server in every storage side Last Mile decodes and recovers the parsed file and 27 arranges the data into one or more data packets in preparation for transport. 28 • In file delivery operation 1775, each parsed file is delivered to the 29 requesting client using independent delivery across the SDNP network in accordance with the SDNP signaling server's routing instructions, e.g. where file storage server 31 1700M sends it file to client 1700A

1 • The incoming parsed data files are further decoded in accordance with the 2 client zone security credentials and the parsed file are merged to recreate the original 3 unparsed file ready for viewing or transfer. 4 The steps are represented in the following sequence of illustrations. In FIG. 97A client device at address "IP Cii" makes a file read request to signaling server 1715 at 6 address "IP S' using data packet 1810A, which includes C&C payload 1811A specifying 7 TCP transport, file related header information, and two or more FS links. The FS links 8 describe the locations of the stored file fragments anonymously using tags or pseudo 9 addresses that must be converted into SDNP addresses or IP addresses for routing. The signaling server 1715, however, does not know the current SDNP addresses for these 11 named user IDs and must request the current information from SDNP name server 1714. 12 In FIG. 97B signaling server 1715 sends data packet 181OB to name server 1714 13 requesting the IP or SDNP addresses of the file storage server nodes F71, F9,4and F9,1. In 14 FIG. 97C name server 1714 sends signaling server 1715 data packet 1810C containing the IP or SDNP addresses of the file storage server nodes F71, F9,4and F9,1. The signaling 16 server 1715 then calculates Last Mile and meshed cloud delivery of the parsed files to the 17 file storage servers. 18 In FIG. 97D, signaling server 1715 sends C&C data packets to the Last Mile 19 nodes located on the storage side, i.e. to zones U7 and U9. As shown, data packet 181OG is forwarded from signaling server 1715 at address S to file storage server 1700H at 21 address "IP F7,i" carrying a C&C payload comprising "File 1 Read Instruction" 1811G. 22 This packet instructs the file storage server to send the file with ID tag 1 from its address 23 "IP F7,i" toSDNP gateway at address "IP Mo,4" using U7 security credentials. 24 Concurrently, data packet 1810F is sent to SDNP gatewayMo,4, the packet being routed from address "IP S" to "IP Mo,4" containing C&C payload 1811F communicating that a 26 data packet with tag 1 should be anticipated by gateway nodeMo,4and when received 27 forwarded onward in the SDNP cloud using Z Isecurity credentials, for example to 28 address SDNPMo,31. 29 A second data packet 18101 is sent from SDNP signaling server 1715 at address "IP S" to file storage server 1700M at address "IP F9," containing a C&C payload 18111 31 containing a "File 3 Read Instruction". This instruction commands file storage server

1 1700M to send a file with ID tag 3 to SDNP gateway ate address IP Mo,s using zone U9 2 security credentials. Other C&C packets (not shown) are similarly sent to the other file 3 storage servers and gateways such as nodes F9,4 and Mo,sas well as the nodes in the 4 SDNP cloud. In FIG. 97E, signaling server 1715 sends data packet 1810D to client device 6 1700A, the packet being routed from address "IP S" to "IP Cii" through router 1702G. 7 Data packet 1810D contains C&C payload 181ID informing the client to expect multiple 8 incoming data packets with tag 1, tag 2 etc. from SDNP gateway 1701U at address "IP 9 Mo,o" using zone U1 security credentials. Concurrently, signaling server 1715 also sends data packet 1810E to SDNP gateway 1701U, the packet being routed from address "IP S" 11 to "IP Mo,o". This packet includes C&C payload 1811E for Last Mile routing in zone U1 12 applicable for incoming data packets identified as tag 1, tag 2 and tag 3 packets 13 transported from within the SDNP cloud. 14 Once the command and control data packets are distributed to the network, the file transfer can ensue. The first step in the transfer is shown in FIG. 98, where data 16 packet 1741R comprising FS Link 3 provides information to SDNP decode operation 17 1751R including exemplary state 920, numeric seed 929, decryption key 1030, and 18 encryption key 1022. On behalf of SDNP decode operation 175IR this information is 19 processed by DMZ server 1752 to execute function involving shared secrets such as packet decryption 1032R, mixing 1061R, de-junking 1053R, and unscrambling 928R, all 21 performed at state 920, the state when the parsed file was last encoded. Note that 22 encryption key 1022 is not specifically needed to decode the file,, but may be used in 23 symmetric key encryption for transporting the parsed file back to the client and file 24 owner. File routing and data transport is shown in FIG. 99 including TCP data packet 26 1720A carrying file 1 from address "IP F7,i" to "IP Mo,4" using U7 security credentials, 27 TCP data packet 1720B carrying file 2 from address "IP F9,4" to "IP Mos" using U9 28 security credentials, and TCP data packet 1720C carrying file 3 from address "IP F9," to 29 "IP Mos" using U9 security credentials. After transport through the SDNP cloud (not shown), the series of data packets 1720X are delivered from the SDNP gateway at 31 address "IP Mo,o" to client address "IP Ci".

1 In the read operation, the data is loaded into the SDNP app in its "read only" 2 form. As long as the file remains sandboxed within a SDNP application, the file is 3 protected by the features of the SDNP application and network and does not rely on the 4 device's operating system's login procedures and weak security provisions. The need for read only access to private documents is pervasive in business. Files generated by a 6 corporation's finance, legal, manufacturing, engineering, and quality departments 7 illustrate examples of material that frequently represent read-only content. In many cases 8 these company private files must be forwarded, i.e. distributed electronically, to corporate 9 executives for review prior to their release. Accidental or premature disclosure of the communicated information can be 11 devastating, carrying severe economic and even legal consequences for a company and 12 personal liability for its officers. For example, a public company's unreleased financial 13 report is strictly confidential until it is published. In the United States, regulation FD or 14 "fair disclosure" means the information must be made publically available to everyone at the same time without preference. If any outside party gains access to that information 16 prior to its public release, it is a violation of regulation FD. If a court determines that the 17 regulation FD violation occurred because the company was negligent in its duty to 18 maintain and insure the document's confidentiality, then the company may penalized for 19 its infraction and its officers may be held personally liable, even if no insider trading resulted from the selective disclosure. 21 Within the SDNP app, a retrieved file is compartmentalized (sandboxed) to 22 prevent transfer of the data from one account identity to another, e.g. files may not be 23 swapped between business and personal accounts. Depending on the reader's 24 authorization privileges, a user may or may not be allowed to download the retrieved file out of the SDNP application and into un-encoded storage in device memory. 26 Downloading the file outside a SDNP enabled application compromises the security of 27 the file and the data it contains. For data residing within a SDNP application, access is 28 controlled, a user's actions are limited, and both the device and the SDNP network must 29 verify the user's identity. Such a multi-tiered multi-factor authentication is far more difficult to overcome than defeating the simple 4-number pin needed to open a phone. In 31 contrast, once a file is downloaded into a computer, tablet, or cell phone, it is nearly

1 impossible to prevent unauthorized access, to determine who has access, or who has 2 made a copy of the file. 3 So using SDNP communication, a file owner can lock, i.e. compartmentalize, 4 sensitive documents and files so that others may read them but not download them into their phone. Additional steps can be used to prevent screen shots or photographs of the 6 LCD display screen. In other cases where security or privacy are not required, transfer of 7 retrieved files from the SDNP app into the phone's memory is enabled and available for 8 use without restriction. 9 In an edit operation, an editable form of the file is downloaded into the device and passed into an application program needed to edit the file. To execute a file request and 11 data exchange, there is no fundamental difference in the SDNP network operation 12 between a file read request and a file edit request other than in the operation of the 13 client's SDNP application - from the perspective of the SDNP network's transfer of data, 14 the operations are functionally equivalent. The differences between the read and edit operations therefore can be considered to reside primarily in the execution of Layer 5 16 through Layer 7 comprising application specific files. 17 To edit the retrieved file, the application may be (i) an device embedded 18 application (such as Simpletext) native to the device's operating system but operating 19 outside of the SDNP application, (ii) a third party application running atop the device's operating system but outside of the SDNP application, e.g. Microsoft Word, Adobe 21 Acrobat, etc., or (iii) a secure application running inside the SDNP application and not 22 directly accessible by the device or its operating system. For example, a corporate press 23 release may be edited within the SDNP application sandbox but cannot be downloaded 24 into the phone's memory. As an added provision for maintaining business security, any file owned by a business, i.e. sandboxed in the SDNP business account compartment, 26 cannot be transferred into the user's personal SDNP account even though both personal 27 and business profiles are running within the same SDNP application. 28 After editing, storage of the edited file back onto the SDNP's file storage servers 29 does not overwrite the existing unless the file owner specifically requests to do so. Instead the second version is stored in addition to the first and elimination of the earlier 31 version requires the user to execute an erase operation. Because HyperSecure file storage

1 invariably requires identity verification, the process of saving the edited file may include 2 unique system features not available from file storage lacking dedicated HyperSecure 3 network communication. Once such unique feature is a signature verification function 4 used to sign and date (or in Asia to stamp/chop and date) the file. The signature function may include a registered receipt sent to the document holder and to the original document 6 creator. 7 For HyperSecure data storage made in accordance with this invention, an erase 8 operation involves overwriting all the existing parsed files with random numbers and 9 optionally doing it again one hour later to further obscure small but potentially detectable analog variations in the electric charge or magnetic field of the stored bit. The file record 11 is also overwritten to confound the data drive's file record. After erasing the data and file 12 record, the client's data link is destroyed in the client device using the SDNP system's 13 self-destructing message feature, and any remnant of the FS link is purged from the 14 SDNP system. If however, a file system administrator has been tracking activity of their user base with third party software, the administrator may still retain metadata on the 16 file's history including its owner, its creation date, who accessed the file and when, and 17 when it was erased, even though they have no access to the file itself 18 The SDNP network and HyperSecure Last Mile functions may also support 19 different features and operating procedures for corporate accounts than for personal account profiles. As described previously, the erase operation on a personal account 21 involves rewriting junk data into the file, purging the drive's index record of the file's 22 existence, and destroying all FS links to the file's previous fragmented storage locations 23 using self-destructing messages. For corporate accounts, however, a file storage 24 administrator may require their prior approval to permanently destroy a file, e.g. using an approval process similar to dialog box 1769 in FIG. 96A but sent to the administrator 26 rather than the file owner. 27 If the company's file administrator chooses not to allow the files deletion, several 28 scenarios may occur including (i) the file owner is notified the file will not be deleted and 29 the file read link is retained in their SDNP application or SDNP communicator message history, (ii) the file owner is notified the file will not be deleted, e.g. it will be preserved 31 for "archive purposes", but their personal file read link will be removed from their SDNP

1 application using the SDNP system's self destructing messages provision, meaning once 2 the owner tries to delete the file only the file storage administrator can recall it, or (iii) the 3 file owner's personal file read link will be removed from their SDNP application using 4 the SDNP system's self destructing messages provision but they are not informed the file has been retained by the company. 6 Because of Last Mile HyperSecurity intrinsic to the operation of the disclosed 7 anonymous fragmented distributed file storage system, without a "file storage read link" 8 the stored files are un-retrievable, even by the file storage administrator. For the 9 administrator to gain access to a file, they must be the corresponding file storage read link whenever a file is saved or edited. While this level of monitoring is possible for a 11 corporate account, the copious amounts of data generated in tracking every change to 12 every file will invariably will overwhelm any file management system. An intelligent 13 filter possible with the disclosed SDNP system as is disclosed is to track only attempted 14 file erasures. In this approach, the administrator does not monitor the creation of files but tracks only attempts to delete them. Whenever a file owner attempts to delete a file, then 16 and only then, is the corresponding file storage read link transferred to the administrator's 17 database or console for approval or archiving. 18 The database size can further be minimized by identifying specific employees and 19 contractors to which monitoring is required. For example, if a company becomes involved in a financial audit or a patent lawsuit, normally the parties are informed not to 21 erase any relevant data or erase any files. Using file management features enabled by the 22 disclosed SDNP file storage system, any file erasure attempts of staff related to the 23 investigation can be tracked by logging the attempted erasure, and "at that time" sending 24 a copy of the file storage link to the file storage administrator or to the independent investigator as the case may be. Such a method is beneficial because it limits the amount 26 of data to be monitored and it naturally alerts management to suspicious activity 27 suggesting an attempted cover-up of wrongdoing. To prevent the accidental or malicious 28 loss of a file storage name link by destruction of the client and file owner's device itself, 29 the use of redundant file storage links as disclosed previously is imperative. In corporate cases, the backup copy may be maintained on computer located within a secured office, 31 or in a centralized company server.

1 In cases of extreme security, e.g. in cases of national security, erasing a file may 2 comprise a multistep method including (i) overwriting the file with random data, (ii) 3 copying all other files off of the storage drive onto some other storage device (iii) 4 performing a bulk erase of the drive, (iv) reformatting the drive, (v) overwriting the drive's storage fields with random numbers, and optionally (vi) copying back the 6 preserved files as required. Unlike a conventional data overwrite of a file a bulk erase 7 process affects the read-write storage medium itself naturally randomizing its electrical, 8 magnetic, or optical properties at the molecular level. Bulk erasing of a magnetic drive 9 can utilize a large electromagnet, bulk erasing of flash may involve elevating the ICs to a high temperature and possibly subjecting them to ionizing radiation at elevated operated 11 voltages. Magneto-optical drives can be bulk erased using high magnetic fields. Re 12 writable optical drives can be bulked erased using a bright scanning laser scanned 13 transverse to the disk format tracks. In any event, bulk erasing represents the extreme 14 case where the storage media after erasing is either completely devoid of data, even at risk of damaging the storage media so that is may never be used again. 16 Another important factor in a HyperSecure distributed file storage system is to 17 maintain the integrity of the file data and the link access. To insure the link is not 18 accidently lost, from time-to-time it is beneficial to reestablish, i.e. reconfirm, the file 19 storage read link and reissue the security credentials. This process, referred to herein as a "refresh link" command can be initiated from the client manually or automatically, and 21 may also be initiated from a file storage server after some predefined interval. For 22 requests initiated from the client, the SDNP signaling server communicates a command 23 and control packet to the corresponding servers. Once a link refresh is initiated as shown 24 in FIG. 100, the files are read and decoded by SDNP decode operation 175IF at state 320X, the "old" state at time ti at which they were previously created using zone U9 26 security credentials. The file is then re-encoded by SDNP encode operation 1750D using 27 new state 920Y at time t2 and saved to the storage drive. The refreshed storage link, e.g. 28 FS link 3, is then sent over the SDNP network back to the file owner, client device 29 1700A. The resulting file comprises encoded data updated with zone U9 security credentials at time t2. The client's security credentials in zone Ul used to create and parse 31 the file originally are not updated however. To read the file, the read operation must first

1 decode the file using zone U9 security credentials at the state corresponding to timet2, 2 and then, after transport to client node Ci, decode the file using zone Z Isecurity 3 credentials associated with the time the file was first made. 4 As another provision for enhanced security, the redistributefileoperation moves every parsed file for a selected file storage link to new or different file storage servers. 6 The operation may send the parsed files to completely new servers, or alternatively the 7 files may be redistributed among existing storage nodes. In each case, the security 8 credentials are updated and a new file FS link issued and sent to the client or clients with 9 access to the file. This operation is shown by example in FIG. 101 where the content of file storage SDNP node F7,1 in zone U7 is decoded by SDNP decode operation 1751H 11 using state 920X, the state at time ti when the file was created. The file is then 12 transported over the SDNP network (not shown) to file storage SDNP node F9,4where it 13 is encoded by SDNP encode operation 1750L using zone U9 security credential as state 14 920Y corresponding to timet2. The file is then stored and an updated FS link 2 is sent to the file owner and other clients with file access. 16 Concurrent to the aforementioned file transfer, the content of file storage SDNP 17 node F9,4in zone U9 is decoded by SDNP decode operation 1751L using state 920X, the 18 state at time ti when the file was created. The file is then transported over the SDNP 19 network (not shown) to file storage SDNP node F9,1 where it is encoded by SDNP encode operation 1750M using zone U9 security credential as state 920Y corresponding to time 21 t2. The file is then stored and an updated FS link 3 is sent to the file owner and other 22 clients with file access. In a similar manner, the content of file storage SDNP node F9,1 in 23 zone U9 is decoded by SDNP decode operation 175IM using state 920X, the state at time 24 ti when the file was created. The file is then transported over the SDNP network (not shown) to file storage SDNP node F7,1where it is encoded by SDNP encode operation 26 1750H using zone U7 security credential as state 920Y corresponding to timet2. The file 27 is then stored and an updated FS link 1 is sent to the file owner and other clients with file 28 access. In this manner all three files are relocated and issued new security credentials and 29 the clients with authorized access are issued new file storage read links based on updated FS links 1, 2, and 3.

1 Another necessary maintenance function performed by the HyperSecure file 2 storage system is the operation used to check for files lacking any live links, i.e. "zombie 3 files." The operation is similar to that of the refresh link operation except that the file 4 storage server, rather than the client or file owner initiates it. In operation, each file storage server tracks the time since a file was last accessed. If the last operation on the 6 file exceeds a specified interval, e.g. one month with no activity, the file storage server 7 contacts the client or clients to confirm if the link is still active. The file storage server is 8 able to contact the client using the same method employed to send the FS link to the 9 client. At the time a file is stored, the file storage server retains a SDNP zip or pseudo address of the client. 11 Should no activity occur during the specified interval, the file storage server then 12 contacts the SDNP signaling server with a request to reconfirm that the link remains 13 active. The SDNP signaling server then plans the delivery route of the FS link 14 verification request for each participating file storage server. Each file storage server then sends its request to the client via the SDNP network. Every participating SDNP client 16 node responds with a confirmation that the file link is still present in the device. If the file 17 link is confirmed, at that time the client has the option to perform a link refresh. If, 18 however, no device responds, i.e. no active file read link remains, then the file storage 19 server informs the administrator that a file link has gone stale or is missing, and after some interval such as one to three months, the unclaimed zombie file is permanently and 21 irrevocably erased. 22 Registered Communication - Another feature of SDNP communication made in 23 accordance with this invention is the network's ability to deliver or store "registered 24 communications". Registered communication involves the HyperSecure delivery of communiques or the HyperSecure storage of files as signed time-stamped messages 26 including the ability to e-sign and e-chop the communication for purposes of establishing 27 legal validity. Registered communication also includes the ability to send a "certified 28 message" a handshaking method confirming receipt of a document or file using a signed 29 or chopped time-stamped reply. All registered communication, while initiated by the SDNP application in a client device, is certified through Last Mile communication, i.e. 31 communication across the Last Mile of the SDNP network. Any attempt by a client to

1 fraudulently alter a stamp confirmation will result in a inconsistency between the 2 message and the network record of the stamp confirmation, i.e. the return receipt. 3 Because of the use of "state" in SDNP communication, i.e. where time and other 4 unique variables are employed to establish the message specific security credentials in communiques and in file storage, time stamping is an intrinsic feature of SDNP 6 communication. This point is exemplified in SDNP communicator application window 7 1800 shown in FIG. 102 where each text message sent and received has a corresponding 8 set of time stamps 1801A and 1801B showing when the message was sent, when it was 9 received, and when it was read. Time information comprising a global time reference established by the SDNP signaling server is delivered to the client over the Last Mile 11 network. The SDNP client app then integrates the time stamp into information display. 12 In a registered communication, the communique generates an official stamp as 13 part of the process. One example of a registered communication process is shown in FIG. 14 103 where a HyperSecure message is executed starting with the optional attach file step 1802 involving dialog box 1803 where the client sending the message or file, i.e. the 16 sender, chooses whether to attach a file to the message and if so using a directory browser 17 to find the file. The command dialog 1804 is next used to send the registered message in 18 accordance with dialog box 1805 choosing whether to use regular or registered delivery. 19 The message is then sent using HyperSecure communication made in accordance with this invention. 21 In "message accepted" step 1806, the receiving party completes a series of steps 22 needed to confirm their identity to access the message and to send an authenticated 23 receipt confirming their acceptance of the incoming message and file. This process starts 24 with receipt authentication operation 1807 where the receiving client is asked to confirm their identity. Without authenticating their identity, the receiving party will not be able to 26 access the message, the message will be destroyed and the sender will be notified of the 27 failed authentication step. In this manner, the sender may be alerted to the possibility that 28 the receiving party may have had their device stolen. Once the identity is confirmed, the 29 receiving party is asked in receipt authorization operation 1808 whether they wish to accept the incoming message and attachment or reject it. If the message in rejected the 31 sender is informed.

1 If the receiving party accepts the message by choosing yes, they must complete 2 receipt administration step 1809 to sign for accepting the message, either by choosing an 3 electronic signature (e-sig), and/or selecting a stamp/chop (e-chop). The sender can 4 specify the options required. In some countries both a chop and a signature are required to be legally binding. A subsequent dialog box (not shown) directs the user to locate their 6 signature or chop in the device's file directory. Alternatively, an audio/video recording 7 may be used as confirmation. The recipient will be instructed what to read during the 8 recording. Once the message is signed, then the message becomes visible to the recipient 9 and the attached file becomes available for viewing and possibly for downloading depending on the sender's requirements. 11 Upon accepting the document, a signed time-stamped message receipt 1811 12 identifying the message recipient, the embedded text and attached filename received, the 13 data and time the message was received, and a signature comprising either an e-sig, an e 14 chop, an audio recording, an audio-video recording, or some combination thereof is sent to the send in acknowledgment operation 1810. In archive receipt option 1812 the sender 16 has the opportunity to save a copy of the signed time stamped message receipt 1811 to 17 the system's HyperSecure file storage system, for which the sender will receive file read 18 link 1813 needed to recall the message. Alternatively, message receipt 1811 may be 19 available for download into the sender's device. Issues with Encryption Based Security - Governmental security agencies argue 21 that in today's world of corporate fraud, IP theft, cybercrime, hacking, criminal gangs, 22 drug cartels, Mafioso, Yakuza, jihadists, and terrorists, any communication system 23 providing callers with untraceable anonymous communication, i.e. systems using 24 encryption to secure data and hide the identity of the caller (metaphorically, a payphone), represents a reckless and irresponsible business practice for the network operator, 26 application developer, and device manufacturer. 27 Unfortunately, it is true that communication relying on encryption to achieve 28 security protects criminals and law-abiding citizens alike. As mentioned previously, this 29 subject has become the focus of countless news stories about the criminal activity of ISIS terrorists and their attacks on Paris and Belgium using a phone application program 31 called Telegram. This app facilitates secure communication using end-to-end encryption,

1 also known as end-user based encryption. Because the decryption keys are held only by 2 the two communicating parties and not by the intervening network or its operator, end-to 3 end encryption is especially troublesome for security agencies. Security agencies rallying 4 against Telegram argue that large-key end-to-end encryption represents a national and even a global security risk enabling terrorists to operate secretly using open 6 communications. Arguments favoring Telegram support personal privacy at any cost. 7 The privacy debate arose again in regards to the December 2n 2015 shooting in 8 San Bernardino, California, killing 14 and injuring 22 when a federal judge ruled in favor 9 of the FBI ordering Apple to assist in "opening" a locked phone allegedly owned by the shooter. In a February 17, 2016, Washington Post article entitled "Apple Vows to Resist 11 FBI Demand to crack iPhone Linked to San Bernardino Attacks". Apple and their CEO 12 cited several reasons for their refusal to comply with the court order. The article is 13 available online at (https://www.washingtonpost.com/world/national-security/us-wants 14 apple-to-help-unlock-iphone-used-by-san-bernardino-shooter/2016/02/16/69b903ee d4d9-11e5-9823-02b905009f99_story.html), 16 Most notably, Apple steadfastly maintained that it was unable to unlock its newer 17 iPhones for law enforcement, even when officers obtain a warrant, because they are 18 engineered in such a way that Apple does not hold the decryption key - essentially 19 raising the specter of yet another example of the challenge of end-to-end encryption. Apple contended that only the phone's user - or someone who knew the password 21 would be able to unlock the phone. The government rebutted that it does not need them to 22 unlock the encryption feature, just disable the features that wipes the phone's memory 23 after ten unsuccessful login attempts. In an online statement, Apple's CEO Tim Cook 24 countered such a step would dangerously weaken iPhone security. "Once created," he wrote, "the technique could be used over and over again, on any number of devices. In 26 the physical world, it would be the equivalent of a master key, capable of opening 27 hundreds of millions of locks - from restaurants and banks to stores and homes. No 28 reasonable person would find that acceptable." He continued, "Opposing this order is not 29 something we take lightly. We feel we must speak up in the face of what we see as an overreach by the U.S. government."

1 The last point advanced by Apple, that the US justice department was 2 overreaching its authority, is a legal argument not a technical position, one echoing the 3 sentiments of constitutionalists and privacy advocates that the state doesn't have the legal 4 right to monitor communications or invade a person's privacy without probable cause. While the particular San Bernardino case clearly meets the bar of probable cause, the idea 6 of creating a universal backdoor that can open any communication device it is argued, 7 invites abuse by authorities. In their February 2 3rd 2016 article, the publication The 8 Atlantic agreed "Apple Is Right: The FBI Wants to Break Into Lots of Phones". The same 9 day The Guardian reported "FBI seeking access to a dozen iPhones, Apple claims". Oddly, the same pro-privacy position was taken by the United States Congress. 11 On March 1 st in a follow up story by the Guardian entitled "Congress tells FBI that 12 forcing Apple to unlock iPhones is 'a fool's errand'", US legislators accused the US 13 Justice Department of overreaching and undermining privacy. "The path to hell starts at 14 the backdoor," Microsoft's general counsel, Brad Smith, told the RSA Conference in San Francisco. Smith challenged the computer security industry represented at the gathering 16 to "stand up with Apple in this important case". 17 During the firestorm, numerous security experts including NSA whistleblower 18 Edward Snowden promulgated the position that unlocking the phone is not as difficult as 19 the FBI purported. Talking via video link from Moscow to the Common Cause Blueprint for a Great Democracy conference (March 8-9), Snowden said: "The FBI says Apple has 21 the 'exclusive technical means' to unlock the phone. Respectfully, that's bullshit." Before 22 the case could even come to court, the FBI reported they had already found a way to 23 break into the locked iPhone. In a March 29, 2016, article Fortune Magazine reported 24 "FBI Might Not Tell Apple How It Cracked the iPhone." The legal and geopolitical fallout of the Apple-FBI case is far reaching. Following 26 the FBI's lead, other nations are expected to insist on backdoors to all communication 27 devices connected to their network - including phones carried by US citizens traveling 28 abroad. Moreover, now that the iPhone has been successfully hacked, criminals will 29 invariably discover or re-invent these methods to engage in new forms of cybercrime and identity theft. Not to be outsmarted by criminals, governments may seek to employ the 31 same methods for expanding surveillance and espionage, and even various departments

1 within the same government may use these methods to spy on the activities of one 2 another. In related stories, various governments are considering limiting the level of 3 encryption used in end-to-end communication. 4 Collectively, these events clearly reinforce the realization that no obvious combination of existing security methods presently available in the public domain insure 6 both security and privacy, at least not without also aiding criminals and terrorists. The 7 problem stems from the exclusive reliance of encryption to achieve both network security 8 and end-to-end security and its associated caller privacy. Increasing the security of text, 9 voice, or files by increasing the bit size of an encryption key makes any communique more secure and difficult to crack. The enhanced security protects business and law 11 abiding citizens in maintaining security and privacy, and in combatting identity theft. 12 Unfortunately, the same enhanced security indiscriminately protects criminals and 13 terrorists from detection, allowing them to operate with impunity and invisibility. 14 This point is illustrated in FIG. 104A where caller 1825A communicates to callee 1825Q over an unsecured network such as Internet 1821 suffering from many avenues of 16 cyber-assaults, i.e. the network has a large "attack surface" of vulnerability. To reduce 17 the attack surface encryption 1026 and decryption 1032 are employed to form an 18 encrypted pipe or tunnel 1820 having a smaller attack surface than network 1821. The 19 problem is determining how big of an encryption key should be used. As shown in table 1824, the larger the encryption key, the more combinations exist and the harder it is to 21 crack the encryption. The encryption is used for two purposes (i) to provide network 22 security for preventing man-in-the middle attacks, and (ii) to insure caller privacy 23 through end to-end security. As shown by line 1823, any improvement in network 24 security results in an equivalent increase in end-to-end security. While high network security is beneficial to prevent malicious outsider attacks, excessive end-to-end 26 encryption is a twin-edged sword. If a large key size, e.g. AES256 or AES512, is 27 employed the system delivers "top secret" network performance and naturally provides 28 the same grade security for the callers. In the event that the caller is a suspected criminal 29 or terrorist, however, neither the network operator nor the government can detect or monitor the caller's activities.

1 The key size tradeoff is complex. If the encryption key is too small, criminals can 2 attack the network and its users as targets. If the encryption key is too large, criminals can 3 use the network to hide their illegal activities and thwart investigator's efforts to detect 4 ongoing fraud and malfeasance. In corporate environments, the company's security policy may reject end-to-end encryption altogether because it prevents monitoring of 6 employee activities or complying with corporate investigations and IP lawsuits. 7 Even determining what size key is breakable and what is secure is challenging, 8 changing with evolution of technology. Referring again to table 1824, the number of 9 possible combinations that must be analyzed in a brute force attack is calculated as a function of a cipher's key size. While a 16-bit key only has 65k combinations, a 56-bit 11 key has 1016 combinations, and a 128-bit key has more than 103 8 combinations. A 256-bit 12 key has combinations 39 orders-of-magnitude larger than the 128-bit key. Ignoring the 13 use of pattern recognition, a brute force attack tries every combination to it cracks a code. 14 In an EETimes article entitled "How secure is AES against brute force attacks?" (http://www.eetimes.com/document.asp?docid=1279619), the authors estimate the time 16 required for a circa 2012 supercomputer capable of 10.5 petaflops to perform a brute 17 force attack. A petaflop is a thousand trillion or 1015 floating point operations per second, 18 or one thousand teraflops. As such, a 56-bit key requires only 399 seconds, a 128-bit key 19 requires 1.02 x 1018 years, a 192-bit key requires 1.872 x 1037 years, and a 256-bit key requires 3.31 x 1056 years. 21 The time required to mount a brute force attack also is changing. Since the article 22 was written, the world's fastest computer has already tripled in speed. Reported in the 23 BBC news article July 30, 2015, entitled "Supercomputers: Obama Orders World's 24 Fastest Computer," investigators report the targeted speed of the next gen supercomputer is twenty times faster than the record holder, i.e. a machine capable of one exoflop, or a 26 billion-billion floating point operations per second. This means that the time needed to 27 crack encryption continues to erode with every passing year. Another newer approach to 28 cracking encryption is to employ massively parallel processing, the same method as 29 Bitcoin mining. Instead of having one super computer, using thousands or millions of computers in parallel allows an attack to proceed concurrently reducing the time 31 proportionately. Today's fastest microprocessors already break 1.1 teraflops so thirty

1 thousand best-in-class microprocessors operating conjunctively equal the world's fastest 2 computer at the present time. Only one million microprocessors are needed to realize an 3 exoflop computer. Dedicated ASICs can further erode the security while quantum 4 computing promises to change compute power by many orders of magnitude. In conclusion, large key end-to-end encryption is not a good solution to achieve 6 privacy and security in communications. The alternative approach enabled by the SDNP 7 network and HyperSecure Last Mile communication as disclosed herein separates end-to 8 end encryption from network security. As shown in FIG. 104B, communication between 9 SDNP clients 1700A and 1700Q, representing caller and callee respectively, is carried by SDNP network 1831. The network's small attack surface is realized by anonymous multi 11 route and meshed data transport using dynamic scrambling, fragmentation, junk 12 insertions, and hop-by-hop encryption, routed using tri-channel communication for 13 control. Although Last Mile communication and every hop within the SDNP cloud 14 involves dynamically changing security credentials, the process is represented in simplified form by SDNP encode operation 1832 and SDNP decode operation 1833. 16 As described by table 1834 and illustrated by line segment 1830, these methods in 17 various combinations achieve security equivalent to secret or top-secret encryption 18 standards without exclusively relying on encryption. Since line segment 1830 is flat, it 19 means there is no interdependence between end-to-end encryption shown on the y-axis, and network security shown on the x-axis. Instead, the network security level can be 21 adjusted from case A to case D by applying a variety of SDNP security methods. These 22 security operations are performed by SDNP software in a manner where the caller and 23 callee are unaware of the security credentials used to transport the data packets across 24 SDNP network 1831 and its various security zones. In particular, the conversing clients do not knowingly participate in any encryption Last Mile network's key exchange. As a 26 distributed network, the use of encryption within the SDNP cloud is unrelated to Last 27 Mile security, and no master keys exist for the system. As such, SDNP network 1831 28 security does not depend on end-to-end encryption performed by encryption 1026 and 29 decryption 1032 to produce encrypted pipe or tunnel 1820. Encryption used by SDNP network 1831 need not utilize the same size keys as 31 end-to-end encrypted tunnel 1820. As shown in the graph, commercial and corporate

1 security applications of end-to end encryption can employ 128b key encryption (such as 2 AES128) illustrated by dotted line 1835 even if the single-hop dynamic encryption within 3 the SDNP cloud employs AES256. In fact, end-to-end encryption can utilize RSA or 4 other cyphers without compromising network security. The SDNP network 1831 is still protected by AES encryption compliant with FIPS140-2 military grade security even if 6 the end-to-end encryption tunnel 1820 is not. As described, the SDNP network 1831 7 protects against all outside cyber-assaults and man-in-the-middle attacks. The end-to-end 8 encrypted tunnel 1820 protects callers from intervention from network operator and other 9 "inside" hackjobs. In this regard, end-to-end encryption in this disclosure is primarily used for insuring caller privacy, not to achieve data packet transport security. 11 Because the end-to-end encryption can be increased or decreased in strength or 12 even eliminated without risking the network's security, the method is adaptable for a 13 wide range of applications. For example, if the 128b key encryption illustrated by dotted 14 line 1835 is too rigorous for small companies or personal use the number of bits can be decreased without giving up personal privacy. In military or government applications the 16 encryption key length can be increased to 192b, 256b or even 512b as required. In this 17 regard, the disclosed SDNP system overcomes the deficiencies with present day 18 encryption based communication, offering features unavailable by any alternative 19 application, device, or network. Security Administration - Another key feature of SDNP communication is its 21 unique approach to security administration. Security administration is required in 22 numerous situations including: 23 • Monitoring of employee communications performed in accordance 24 with HR policies or employee investigations, • Monitoring and recording of employee communications in support 26 of financial audits, forensic accounting, or fiscal reporting, 27 • Documenting intercompany communications as part of a merger 28 and acquisition transaction, 29 • Documenting intercompany communication as part of IP or corporate litigation,

1 • Complying with demands for communiques and documents in 2 accordance with subpoenas and criminal investigations, 3 • Complying with legal orders for account information, call and 4 message monitoring, and file access in matters of national security. With proper authorization, a SDNP network administrator can facilitate access of 6 SDNP network traffic to a designated "SDNP security agent" for the purpose of 7 communication monitoring and data surveillance. The process by which a SDNP security 8 agent is established and enabled involves a multi-tiered approval and authentication 9 process necessarily performed in advance of the monitoring activity. To prevent abuse, no one individual is capable of independently commencing monitoring, not even a SDNP 11 network administrator. Because of the dynamic nature of SDNP communication as a 12 distributed network lacking central control, having no master network keys, and 13 employing dynamic SDNP encoding and decoding executed using zone-specific security 14 credentials operating in offline in DMZ servers, there is no mechanism to recover data or recall conversations expostfacto. Data resides within the SDNP network for only short 16 durations, typically less than 100 milliseconds. As a distributed system, by design the 17 SDNP network intrinsically lacks central control, without which even metadata of prior 18 calls is unavailable. As such, the SDNP network only supports apriorisecurity 19 monitoring, meaning monitoring by a designated SDNP security agent must be established in advance of intercepting communiques. 21 Moreover, because of the dynamic nature of fragmented meshed communication 22 within the SDNP cloud, no SDNP node within the cloud, i.e. beyond the SDNP gateway, 23 carries the data packets of a complete conversation. Most nodes carry no more than 5% of 24 the data and typically only for 1Oms at a time before the routing changes. In accordance with SDNP communication, dynamic routing constantly redirects communication 26 through different media servers. As such, cloud access is not useful for recovery or 27 monitoring of communiques. Although the SDNP cloud's data packets can be captured, 28 they comprise a useless jumble of unrelated sounds, data, conversations, and junk data. 29 Instead, monitoring by a designated SDNP security agent can only productively occur in the Last Mile where the complete set of related data packets necessarily traverse, either 31 within the client device or preferably in the SDNP gateway.

1 An example of data packet routing in security monitoring is shown schematically 2 in FIG. 105A where SDNP security agent 1840 monitors a conversation between SDNP 3 client device 1600A and SDNP client device 1600H. While the conversation occurs using 4 data packets sent from SDNP client device 1600A through Last Mile router 1602G to SDNP gateway 1701U and through the SDNP cloud, data packets sent from client device 6 1600A are closed by SDNP gateway 1700U and securely routed to designated SDNP 7 security agent 1840. Specifically, during UDP transport, Last Mile data packet 1630A 8 carries SDNP data 1 from the SDNP client at address "IP Cii" to SDNP gateway at 9 address "IP Mo,o" emerging from SDNP gateway at address "IP Mo,4" and being delivered over zone U7 Last Mile to SDNP client address "IP C7,1". During authorized monitoring, 11 cloned SDNP data 1 is securely delivered to SDNP security agent 1840 at SDNP address 12 "IP SA". The cloned monitoring data packet 1841 operates in the same manner as a 13 SDNP group-call except that the duplicate data clones are invisible to the callers. The 14 callers are therefore unaware they are being monitored. Security monitoring works for incoming calls as well. In FIG. 105B, SDNP data 16 7 is sent from client device 1600H with address "IP C7,1" to SDNP gateway at address 17 "IP Mo,4". After SDNP cloud transport, the data is delivered from SDNP gateway at 18 address "IP Mo,o" to two destinations. The first destination, client 1600A at address "IP 19 Cij", receives reply data packet 1640A containing SDNP data 7. The second destination, SDNP security agent 1840 receives an identical payload containing cloned data "SDNP 21 data 7" via data packet 1842. Delivery of data packet 1842 is invisible to the callers so 22 they are unaware they are being monitored. 23 The same method is applicable for monitoring of fragmented distributed file 24 storage. Rather than capturing the fragmented data files, however, the security agent need only receive a copy of related FS links. Such as example is shown in FIG. 106 where 26 SDNP file storage device 1700H sends data packet 1740H containing FS Link 1 from 27 address "IP Fi,i" to gateway address "IP Mo,4" which after being routed through the 28 SDNP cloud is forwarded to client 1600A by data packet 1740A. The cloned payload "FS 29 link 1" is also delivered to SDNP security agent 1840 at address "IP SA" by data packet 1843 sent from gateway address "IP Mo,o". As in the case of real time communication, 31 the file owner, client 1600A, is unaware of being monitored by the SDNP security agent.

1 The same monitoring mechanism works for multi-route Last Mile communication 2 where data packets enter and leave the SDNP cloud through more than one SDNP 3 gateway. This case is illustrated in FIG. 107 where Last Mile communication from client 4 device 1600A comprises split data packets 1630A containing payload SDNP data 1 and data packet 1630B carrying payload SDNP data 2 entering the cloud through SDNP 6 gateways 1701U and 1701V respectively. After SDNP cloud routing the data packets 7 recombine and are shown emerging from the cloud as a single data packet 1630L with a 8 payload containing the combined data SDNP data 3. In operation, SDNP gateways with 9 addresses "IP Mo,o" and "IP Moi" are instructed by the signaling server to create clones of incoming SDNP data 1 and SDNP data 2 from client node Ci, and to direct them to 11 SDNP security agent 1840 at address "IP SA". The cloned data is sent in data packets 12 1841A and 1841B using the same HyperSecure methods used for all SDNP data transport 13 except that the security agent operates in its own unique security zone, i.e. zone SA using 14 credentials unavailable to any other device. As such, there is no record or proof that a designated security agent ever monitored a particular conversation. 16 Because SDNP monitoring activities are clandestine and essentially equivalent to 17 an undetectable invisible conference call, it is critical to the SDNP system employs 18 independent checks to approve and confirm the use of network monitoring and to 19 designate and confirm the SDNP security agent authorized to execute the monitoring. The SDNP security agent can be any SDNP client except for the network administrator. 21 As a safeguard against system corruption, any SDNP network operator or SDNP 22 administrator is not allowed to act as a SDNP security agent, i.e. those administrating the 23 network cannot subvert its capabilities for their own use even should they be threatened 24 or blackmailed. The SDNP security agent may constitute an individual, a government agent, a 26 government designated representative, or a law officer. The particular requisite 27 qualifications of a designated security agent vary by company or country in accordance 28 with applicable local law. A SDNP security agent's monitoring hardware may comprise a 29 communication device or a computer server with recording, data storage, and sophisticated decryption capability. All communication sent from the SDNP network to 31 the designated SDNP security agent is transported with the same HyperSecure

1 communication as the client's communiques themselves, and therefore security 2 monitoring does not compromise the confidentiality of the call or the caller's privacy 3 except for the monitoring performed by the authorized security agent. 4 Moreover, the implementation of monitoring and the allowed capabilities of an authorized SDNP agent does not compromise network integrity and security in a means 6 whatsoever. No operating details or DMZ shared secrets are revealed to the network 7 operator or to any security agents - operation of the SDNP system occurs automatically 8 and autonomously without the intervention or involvement of human operators while the 9 DMZ servers provide security using zone specific credentials not available through online access. Security monitoring, therefore, does not degrade system security or render 11 the SDNP network vulnerable to cyber-attacks. 12 Data payloads are delivered to SDNP security agent in the same form they are 13 created by the caller. As part of delivery to the SDNP security agent, all network SDNP 14 encoding is decoded so that no network securityprovisions are present in the delivered data packets. If, however, the client employs end-to-end encryption, the SDNP security 16 agent will have to break the client's end-to-end encryption unless the client agrees in 17 advance to share end-to-end decryption keys with the network or to use and independent 18 key server utility accessible by the SDNP network. To reiterate, such end-to-end 19 encryption and decryption keys are primarily included in the SDNP method for privacy purposes and are unrelated to any encryption used in the SDNP dynamic encoding 21 function. 22 To minimize the risk of monitoring abuse, SDNP administration used to establish 23 and authorize a designated SDNP security agent to monitor a client or group of clients is 24 a multistep process. While the SDNP system includes provisions for performing monitoring, the legal application of this feature is the responsibility of the network 26 operator, the network administrator, and authorizing agency or agents. Together these 27 parties are personally responsible to insure monitoring is performed legally and in 28 compliance with the laws of the country in which the monitoring is performed. 29 The need for monitoring could arise from any number of situations. In a company, a whistleblower complaint or a claim of sexual harassment could trigger a HR 31 investigation or precipitate forensic accounting. A court subpoena associated with a

1 litigation matter (potentially including a gag order) may also require monitoring. In 2 corporate matters, communication using the company SDNP network is generally limited 3 to company communiques and does not cover private and personal communications. In 4 most countries, private communication is protected unless criminal intent is suspected. In cases of national security or law enforcement actions, both public and private SDNP 6 accounts of a caller may be subject to monitoring. In such cases, the corporate SDNP 7 network operator for the company would implement the monitoring process for company 8 communications, while independent telecommunication SDNP network operator would 9 be the only provider in a position to execute monitoring of the caller's private communications. In some countries, the government must present a judge-approved 11 subpoena to commence monitoring of private citizens while in other countries a 12 government may assert the authority to monitor any and all private communication on a 13 defacto basis. In cases of international communication, it is more difficult to determine 14 which laws are applicable and what the network's position on enabling call monitoring should be. 16 One example of the AAA process used to enable monitoring is illustrated in FIG. 17 108. The process to approve the monitoring of a client involves the network administrator 18 1850 used to set up the monitoring operation, the security agent 1840 in charge of 19 monitoring the client, and three authorizing agents 1851A 1851B, and 1851C used to approve the monitoring process, preferably operating autonomously and independently 21 from the network operator or network administration. The process starts with the network 22 administrator 1850 seeking monitor request 1862 in response to an investigation or court 23 order. Using a command dialog box 1862, the administrator identifies the phone number 24 of the individual for which monitoring is being requested. If the request is to monitor a group of people, they can be entered one by one into the system of a file listing the all the 26 parties and their associated phone numbers can be uploaded into the system. 27 In authorization step 1863, the network administrator 1850 identifies a candidate 28 security agent 1840 recommended for performing the monitoring function using 29 exemplary dialog box 1864. In corporate cases, the individual may be an HR director, legal counsel, a member of the audit committee, and independent accounting firm 31 representative, or an independent investigator. In legal cases the security agent may be a

1 law officer, district attorney, FBI agent or other duly appointed investigating committee 2 member, e.g. in cases of government malfeasance such as a special prosecution 3 committee investigations panel. The system then checks with SDNP name server 1714 to 4 insure that the security agent has an SDNP account and that they comply with the rules specified by the company or network operator. In some cases involving national security 6 a follow-on investigation of the proposed security agents credentials and criminal record 7 may be performed before they are approved. 8 Once the security agent is approved, in authorization step 1865 the request for 9 monitoring is forwarded to authorizing agents 1851A, 1851B, and 1851C, who review the information presented in dialog box 1866 including the name of description of the 11 subject, the name or position of the security agent tasked to perform the monitoring, the 12 expected duration of the monitoring probe, and the reason for the probe. Each authorizing 13 agent can accept or reject the request. The rules of the network operator or company then 14 determine if the monitoring operation is approved based on unanimous approval of the authorizing agents or by simple majority. The identity of the authorizing agents may be 16 known, as in corporate cases, or in criminal cases their identities may remain anonymous 17 protected by the anonymous communication features of the SDNP network. 18 Once the monitoring is approved, in administration step 1867, the database 1868 19 of clients is updated in name server 1714 to tag the SDNP client to be monitored and to identify the SDNP client authorized as the security agent, in this example the shaded row 21 of data. The SDNP addresses in this database are updated together on a daily basis when 22 the SDNP addresses are shuffled to maintain the same relationship between the client 23 being monitored and the designated security agent. Once the date of the probe expires, 24 the monitoring link is automatically severed. In administrative step 1869, the SDNP security agent 1840 is sent a link enabling them to receive all ongoing communication of 26 the identified client being monitored. Their use of this information is not a matter of 27 SDNP network operation. The unauthorized release of a person's private information by 28 the security agent may constitute a crime for which the security agent is wholly 29 responsible. Through this inventive monitoring method, the SDNP network is thereby capable 31 of supporting criminal investigations of malfeasance and potential terrorist activities

1 while maintaining a secure communication medium for law-abiding citizens. The SDNP 2 network is able to securely deliver to authorities private client communication in 3 compliance with legal court orders without risking the privacy of innocent civilians or 4 compromising the security of the SDNP global communication network. Since no backdoor or master key was employed in honoring the court order future communication 6 over the SDNP network remains anonymous and HyperSecure. In this manner the secure 7 dynamic communication network and protocol and its HyperSecure Last Mile 8 communication is able to offer security features not available by any other means and 9 completely avoids the risk of aiding criminality and terrorism created by the excessive reliance on end-to-end encryption employed by OTTs and virtually every messenger and 11 communicator app. 12 Overcoming SS7 Vulnerabilities - If the Apple-FBI controversy was not enough 13 trouble for the communications and security industries, a 60 Minutes episode 14 (http://www.cbsnews.com/news/60-minutes-hacking-your-phone/) revealed severe security vulnerability with Signaling System 7 or SS7, the signal control channel for 16 conventional wireless telephony. As clearly demonstrated in the show, the SS7 17 vulnerability potentially exposes every smartphone and connected device to packet 18 sniffing and cyber-attacks, allowing eavesdropping of wireless conversations and viewing 19 of SMS text, attached files, and pictures simply by knowing a person's phone number. Signaling System 7 is a telephony signaling protocol developed in 1975 used in 21 all forms of digital telephony globally. It comprises a message transfer part or "MTP" 22 operating on PHY layer 1, data link layer 2, and network layer 3 to handle the routing of 23 calls. End-to-end routing is managed using a signaling connection control part or "SCCP" 24 operating at the transport Layer 4. The protocol also includes a number of application Layer 7 functions involved in billing, roaming, and call authorization. The SS7 protocol, 26 albeit unavoidably necessary, is extremely vulnerable to attack and represents a severe 27 risk to securing conventional telephony. 28 In April 2016 (https://en.wikipedia.org/wiki/SignallingSystemNo._7) a U.S. 29 Congress oversight committee reported "the applications for this vulnerability are seemingly limitless, from criminals monitoring individual targets to foreign entities 31 conducting economic espionage on American companies to nation states monitoring US

1 government officials. . . The vulnerability has serious ramifications not only for 2 individual privacy, but also for American innovation, competitiveness and national 3 security. Many innovations in digital security - such as multi-factor authentication using 4 text messages - may be rendered useless." SS7 cyber-attacks essentially come under the category of packet sniffing, 6 intercepting both content and metadata by using the specific formatting of SS7 7 information as a guide. The SS7 protocol essentially provides an information template by 8 which packet information can be interpreted. As shown in FIG. 109, the problem starts 9 with the SIM card or "subscriber identity module", containing various types of personal information about a subscriber and their account. As shown, carrier SIM card 1880, 11 generally issued by a network provider, is used to identify a phone 32 to a cellular 12 network illustrated by antennas 25A, 25B, and 25C with corresponding radio links 28A, 13 28B, and 28C. Each SIM card includes a unique identifier, the ICCID or "integrated 14 circuit card ID" an 18- or 19-digit number used to internationally identify the SIM card. The international mobile subscriber identity or IMSI identifies the individual operator 16 network, i.e. the home network that the SIM card works on. The local network provider 17 uses the IMSI number to communicate with the SIM card to establish calls. 18 The SIM card also includes a "mobile country code" or MCC a three-digit 19 number to identify the country where the SIM card originated. When placing international cellular phone calls from a mobile phone, the MCC is required as part of the 21 dialing sequence. Examples of MCCs include 310 - 316 for the United States, 234 - 235 22 for the United Kingdom, 460 for China, 208 for France, 250 for Russia, 262 for 23 Germany, 302 for Canada, and 724 for Brazil. The MCC is used in conjunction with a 24 "mobile network code" or MNC to identify the network provider that issued the SIM card. A complete list of codes is listed online at 26 https://en.wikipedia.org/wiki/Mobilecountrycode. The SIM card also includes a 15 27 digit "mobile station international subscriber directory number" or MSISDN to uniquely 28 define the subscriber and the type of network the SIM operates on. The SIM card also 29 holds a user phone number and a SMS text directory including a record of incoming and outgoing calls and texts sent along with time and date information. In recent years,

1 carriers have begun using specialized SIM cards with so-called secure elements to store 2 credit card credentials in order to facilitate mobile payments. 3 Because the MCC, MNC and MSISDN codes are transmitted as part of the 4 connection process, the home country and carrier of any SIM card and the subscriber's associated phone number can easily be identified by SS7 intrusions and packet sniffing. 6 The transmitted data 1881 can easily be used to trace the identity of the caller through 7 phone directories, online information, or social media, i.e. through profiling. Once 8 identified and correlated, the phone number and SIM can be used to monitor the activities 9 of the subscriber no matter where they may travel globally. Encryption does not obscure the underlying call information or metadata. Even with end-to-end encryption, data 11 packets can easily be identified as being from the same conversation, captured and stored 12 for subsequent deciphering attempts. 13 Aside from metadata and content, a caller's location is also compromised by the 14 SS7 vulnerability. In any cellular network, the phone sends out messages to the local cell towers identifying it is available in the particular cell. These registration packets are sent 16 at regular intervals. Monitoring these packets allows the location of a phone with a 17 particular SIM card to be located even if the phone is not in a call and even if GPS is 18 turned off. In such a manner, the location and travel of a subscriber can be tracked 19 without their knowledge. Despite SS7 intrinsic vulnerabilities, HyperSecure Last Mile communication 21 made in accordance with the secure dynamic communication network and protocol repels 22 SS7 attacks by obscuring meaningful call data in the Last Link. In particular, 23 HyperSecure Last Mile communication offers significant security advantages over 24 conventional telephony or OTT Internet communications including the following: • HyperSecure Last Mile communication does not reveal the phone 26 number or IP address of the party being called or messaged, even if that party is 27 not a SDNP client. 28 • HyperSecure Last Mile communication does not identify if 29 sequential data packets are part of the same call or represent unrelated data packets with differing destinations.

1 • By hiding the call specificity of data packets, HyperSecure Last 2 Mile communication obscures metadata regarding call times. 3 • HyperSecure Last Mile communication dynamically encodes 4 payloads, preventing unauthorized access to packet contents and protecting the privacy of voice, video, and text communication as well as pictures, files and 6 other content. 7 So as described, communication using the disclosed secure dynamic 8 communication network and protocol and HyperSecure Last Mile communication is not 9 affected by SS7 vulnerability. Since SDNP communication occurs using its own protocol and is carried by encoded payloads, no call data or content can be extracted from an 11 SDNP data packet even for packets carried over an open unencrypted channel such as 12 2G, 3G, and 4G/LTE telephony. Packet sniffing is, therefore, ineffective in launching 13 cyber-attacks against SDNP coding and fragmented data transport. 14 SDNP Camouflaging - Given the foregoing, the only impact SS7 vulnerability has on SDNP communication is in revealing a caller's location. Because the phone 16 number in a carrier's SIM is linked to each user's identity, whenever the cell phone is 17 turned on it necessarily communicates with the nearest cell phone towers even when no 18 phone call is occurring. This cell tower information can then be used to triangulate a 19 user's location and trace a subscriber's travels even with GPS turned off. Since such unauthorized tracking relies on SS7, devices using a conventional carrier's SIM cards are 21 vulnerable to location tracking, even those operating as SDNP clients. 22 As shown in simplified network schematic FIG. 110, an enhancement to Last 23 Mile HyperSecure communication referred to herein as "SDNP camouflaging" thwarts 24 subscriber tracking altogether. To implement this feature, the normal carrier SIM card 1880 is replaced with a SDNP SIM card 1882. The SDNP SIM card is registered to the 26 SDNP network operator, not to the subscriber, so that no personal subscriber information 27 is contained with SDNP SIM card 1882. The SDNP SIM card 1882 is similar to a prepaid 28 SIM card in that it has network access but lacks any personal information. Instead 29 personal information of the account holder is all safely contained within the SDNP network name servers and not accessible to hackers or susceptible to cyber-attacks.

1 In operation, SDNP camouflaging hides the true identity of the owner by 2 employing a SIM card 1882, known only to the SDNP network operator. As such, the 3 phone number contained within the SIM card is used to establish a PHY Layer 1 and data 4 link Layer 2 connection 28B between cell phone 32 and cell tower 25B but not to provide routing. Instead the data packet source and destination addresses for Last Mile routing are 6 managed by SDNP app 1335A and SDNP gateway 1601A in accordance with 7 instructions from SDNP signaling server 1603A. 8 Routed through SDNP gateway 1601A, calls from the SDNP app appear with a 9 different number than the SIM card number. This translation from the physical SIM card number to the SDNP phone number is performed by SDNP name server 1604A, which 11 during call routing translates the SDNP phone number into the SIM phone number in 12 accordance with translation table 1885, thereby camouflaging the physical SIM card 13 number to any users. Using SDNP camouflaging, the true identity of the phone's owner is 14 completely hidden. To place a call to the SDNP client, outside callers place their call to the SDNP # even if they are not SDNP clients themselves. The SDNP network 16 automatically routes the call to the SDNP client without ever revealing the SIM card 17 phone number. Similarly a SDNP client places a call out to non-SDNP callee, the call 18 recipient sees an incoming call from the SDNP #, not from the SIM card number. In this 19 manner, the SDNP performs a function in telephony similar to that of a NAT gateway in Internet communication except that the SDNP system is a real time network and the 21 Internet is not. 22 Because the true user identity of phone 32 is never revealed by call 28B, 23 triangulating the location of the phone is not useful because its user and all 24 communication remain anonymous. As such, tracking the location of unidentified cell phones is not beneficial to hackers, and circumvents SS7 vulnerabilities. In the event that 26 an SDNP client is traveling internationally, the traveler can purchase a local prepaid SIM 27 card and link it to their SDNP number. The SDNP subscriber will still receive calls 28 placed to their SDNP phone number, but the Last Link will occur using the local SIM 29 card thereby avoiding roaming charges. In this manner a single SDNP phone number functions as a global number without long distance expenses.

1 SDNPSubnets - Using its unique SoftSwitch software-based communication 2 nodes, the SDNP communication cloud can be deployed remotely across any network of 3 interconnected computers, private or publically hosted. Examples of server networks 4 include privately owned publically leased networks such as those hosted by Microsoft, Google, and Amazon. FIG. 111 illustrates two SDNP clouds deployed across two 6 separate server networks. As shown, the SDNP cloud comprising servers 1901A, 1901B, 7 1901C, and 1901D hosts SDNP communication nodes Mo,o, Mo,4, M,7, and Mos, 8 respectively. A second SDNP cloud comprising servers 1902A, 1902B, and 1902C hosts 9 SDNP nodes Mio,o, Mio,, and M1,2, respectively. Because they utilize separate security credentials, zone ZO and zone Z1O respectively, the two SDNP clouds are completely 11 distinct and unable to share information directly. A single SDNP client shown as cell 12 phone 32 running SDNP app 1335 may however with proper authorization access both 13 clouds even though they are hosted by different computer server lease providers. As 14 shown by example, SDNP client Ci, is able to access SDNP gateway node M,7 in the zone ZO cloud using HyperSecure Last Mile communication through router 1910 and to 16 access SDNP gateway node Mio,o in the zone Z10 cloud using HyperSecure Last Mile 17 communication through the same router 1910 without risk of comingling the 18 conversations or data packets. 19 Access to the two independent clouds is made through a common communicator application UI/UX 1920. Access to each cloud is compartmentalized in separate dialog 21 sandboxes 1921A and 1921B. Although information may be downloaded from personal 22 account sandbox 1921A into the phone, exporting data from business account sandbox 23 1921B depends on the business and the company's security administration. 24 Connecting a device to the SDNP clouds requires installation of a SDNP app, either as software or firmware, into the device. Installation involves (i) downloading the 26 application (ii) confirming the device identity with a SDNP network generated 27 authorization code (iii) establishing personal identification credentials, and (iv) receiving 28 approval to join a specific SDNP cloud. Once activated, the SDNP application creates 29 HyperSecure Last Mile connection to the independent SDNP clouds. In many cases identity validation and user authentication for the business account are more elaborate

1 than that needed for personal account access, and may entail multi-factor authentication 2 methods. 3 Because of SDNP communication is software-based, with distinct and separate 4 security credentials for each communication cloud, there is no interaction between any installed SDNP communication networks even when hosted by the same servers. With 6 zone specific security credentials uniquely defining each customized SDNP cloud, no two 7 SDNP clouds are alike and are therefore unable to share data directly. Beneficially, 8 multiple SDNP clouds can co-exist within the same server or server network with no risk 9 of data leakage. Access to a business network is controlled, as defined in accordance with the cloud owner's requirement. As such, comingling of the two accounts and 11 communication clouds is prohibited when sharing common host servers, operating with 12 the same security as if two different phones were required to connect to the two separate 13 networks. The autonomy of zone specific SDNP clouds, or "subnets" is further 14 demonstrated in FIG. 112 where servers 1901A, 1901B, 1901C, and 1901D host two clouds simultaneously - one cloud comprising zone-ZO SDNP communication nodes 16 Mo,o, Mo,4, M,7, and Mos, respectively, and a second comprising zone-Z7 SDNP 17 communication nodesM7,, M7,4, M7,7, andM7,s. Despite operating within the same 18 servers, HyperSecure communication using the SDNP established protocols prevents any 19 direct data exchange. Access is therefore managed by Last Mile communication, not through direct inter-cloud data exchange. 21 SDNP communication is not limited to privately leased publically available 22 servers but may also be customized for different types of corporations or government 23 agencies. In fact, private corporations often prefer to host their own networks, especially 24 in business critical applications. Examples of private networks include FedEx, Walmart, IBM, etc. For confidentiality's sake, networks used by research institutes, universities, 26 and medical centers are also frequently self-hosted. Private server networks are also 27 employed to host global business cloud applications such as SalesForce.com, Box.com, 28 Dropbox, eTrade, SAP, etc.; ecommerce platforms and comparison-shopping networks 29 like eBay, Amazon.com, Priceline.com, e-Insurance; media streaming services like YouTube, Amazon Prime, Netflix, Hulu, Comcast Xfinity; and social media such as 31 Facebook, Twitter, and Snapchat.

1 In larger corporations, the IT department may choose to operate separate networks 2 for the parent entity and its subsidiaries. In many privately hosted businesses, however, 3 infrastructure costs are considered an important factor in network design. Rather than 4 supporting two completely different hardware based systems, the SDNP system offers a company the ability to deploy its networks using a combination of separate and shared 6 server resources. As illustrated in FIG. 113, two legal entities, e.g. a parent corporation 7 and its subsidiary, co-host a server network comprising both separate and shared servers. 8 In particular, servers 1903, 1904B, 1904C, and 1904D host zone Z7 communication 9 nodes M7,, M7,4, M7,7, and M7,s, respectively for the parent corporate entity while servers 1901A, 1901B, 1901C, and 1903 host corresponding zone Z communication nodes Mo,o, 11 M,4, M,7, and Mo, for the company's local subsidiary. As illustrated, server 1903, by 12 example, hosts two SDNP communication nodes, namely node M7,, for the parent entity 13 and node Mo,s for the subsidiary. Because of their distinct security credentials, no data is 14 shared directly between parent and subsidiary SDNP clouds even though server 1903 and others (not shown) are shared by both entities. While employees are generally limited to 16 accessing only the cloud of their employer, in the case of corporate officers, access to 17 both clouds may be required. Properly authorized users like that shown by SDNP 18 communicator app U/UX 1920 include separate dialog sandboxes 1921C and 1921D for 19 the various legal entities. In this way one cell phone or tablet can access multiple SDNP clouds of different legal entities with no risk of comingling data, as if the user were 21 carrying multiple phones. 22 The multi-profile feature of the SDNP app using Last Mile HyperSecure security 23 credentials to enable or prohibit access to multiple SDNP clouds supports a limitless 24 number of account profiles from a single SDNP app. In FIG. 114 for example, SDNP client Ci, is able to place global calls without long distance fees over the zone Z99 global 26 SDNP telco comprising servers 1909A through 1909E hosting SDNP nodes M99,1 27 through M99,5 respectively but also to gain access to other clouds, e.g. zone Z9 corporate 28 cloud comprising servers 1905A, 1905B, and 1905C hosting SDNP nodes M9,o, M9,4, and 29 M9,8 and also to call to subscribers of zone ZO cloud through servers 1901A, 1901B, and 1901C hosting SDNP nodes Mo,o, Mo,4, and Mo,s respectively. Access privileges to any 31 given cloud are enforced through Last Mile communication to the SDNP gateway and

1 managed by the system's SDNP signaling server and SDNP name server used to 2 administer authorized users. 3 SDNP communication is equally applicable in high security and restricted access 4 networks needed for government and security. For example, in the United States security restricted communication is needed by a variety of departments including local and state 6 law enforcement, FBI, US National Guard, U.S. National Security Agency, U.S. armed 7 forces (separately andjointly), the U.S. state department, along with congressional and 8 legislative server networks. Other countries similarly host separate networks for various 9 government agencies. To support access to a specific cloud on a "need-to-know" basis, nested subnet 11 architectures can be implemented using SDNP communication methods and technology. 12 For example, in FIG. 115 a nested SDNP cloud structure includes a secure cloud 13 comprising leased computer servers 1907A through 1907D hosting SDNP 14 communication nodes Mo,o , MO,4 , MO, 5, and M, 9, respectively. Communication in this outer network "shell" involves zone ZO security credentials and is displayed in "secret" 16 level dialog sandbox 1912E as displayed in SDNP communicator 1920. The nested cloud 17 also includes an enhanced security inner core with zone Z8 security credentials 18 comprising government-hosted servers 1906A, 1906B and 1906C and corresponding 19 SDNP server nodes M8 ,0, M 8,2 , and M 8,4 . For client C 1,1 to gain access to the zone Z8 core they must have "top secret" security clearance, and communicate through hardened 21 communication sandbox 1921F. One exemplary government application of this 22 technology is in the U.S. State Department where top-secret communication in zone Z8 is 23 restricted to access by ambassadors and the Secretary of State, while other U.S. embassy 24 staff across the world are limited to HyperSecure "secret" communication using zone ZO security credentials. 26 The reference to any prior art in this specification is not, and should not be taken 27 as, an acknowledgement or any form of suggestion that such prior art forms part of the 28 common general knowledge. 29 It will be understood that the terms "comprise" and "include" and any of their derivatives (e.g. comprises, comprising, includes, including) as used in this specification, 31 and the claims that follow, is to be taken to be inclusive of features to which the term 32 refers, and is not meant to exclude the presence of any additional features unless 33 otherwise stated or implied.

Claims (25)

1. A method of transmitting data packets from a client device to a cloud, the data packets being comprised in a communication, the cloud comprising a plurality of media nodes and a plurality of gateway nodes, wherein: the client device transmits a call request to a signaling server, the call request containing contact information regarding a party to be called; the signaling server develops routes for a communication directed to the party to be called, a first route comprising a first gateway node and a second route comprising a second gateway node, neither the first gateway node, the second gateway node; nor any other media node having information describing either the first route or the second route in total; the signaling server transmits routing instruction packets to the client device, the first gateway node and the second gateway node, respectively; and in response to a routing instruction packet, the client device transmits a first data packet in the communication from the client device to the first gateway node and a second data packet in the communication from the client device to the second gateway node.

2. The method of Claim 1 comprising transmitting the first data packet from the client device to the first gateway node over a first physical medium and transmitting the second data packet from the client device to the second gateway node over a second physical medium.

3. The method of Claim 2 wherein the first physical medium comprises a cellular telephone link and the second physical medium comprises a WiFi channel.

4. The method of Claim 2 comprising providing the first data packet with a first IP source address and providing the second data packet with a second IP source address.

5. The method of Claim 1 comprising providing the first data packet with a first IP source address and providing the second data packet with a second IP source address.

6. A method of transmitting data packets from a client device to a cloud, the data packets being comprised in a communication, the cloud comprising a plurality of media nodes and a plurality of gateway nodes, the method comprising: transmitting a first data packet from the client device to a first gateway node through at least one router; providing the first data packet with a first IP source address and a first MAC source address; transmitting a second data packet from the client device to a second gateway node through at least one router; and providing the second data packet with a second IP source address and a second MAC source address.

7. The method of Claim 6 comprising transmitting the first data packet from the client device to the first gateway node over a first physical medium and-transmitting a second data packet from the client device to the second gateway node over a second physical medium.

8. The method of Claim 7 wherein the first physical medium comprises a cellular telephone link and the second physical medium comprises a WiFi channel.

9. A method of transmitting data packets from a client device to a cloud through at least one router, the data packets being comprised in a communication, the cloud comprising a plurality of media nodes and a plurality of gateway nodes, the method comprising: providing a first data packet with a first IP source address and afirst MAC source address; and providing a second data packet with a second IP source address and a second MAC source address.

10. The method of Claim 1 wherein before the signaling server transmits routing instruction packets to the client device, the first gateway node and the second gateway node, respectively, the signaling server contacts a name server with the contact information regarding a party to be called.

11. The method of Claim 10 wherein the contact information regarding the party to be called comprises a confidential identification of the party to be called and wherein the name server converts the confidential identification into an SDNP address of the party to be called, the signaling server using the SDNP address of the party to be called in developing the routes for the communication from the client device to the party to be called.

12. The method of Claim 10 wherein the contact information regarding the party to be called comprises a phone number and wherein the name server converts the phone number into an address of a gateway node closest to the location of the party to be called, the signaling server using the address of a gateway node closest to the location of the party to be called in developing the routes for the communication from the client device to the party to be called.

13. The method of Claim 10 where the client device passes information to the name server whenever the device connects to the network.

14. The method of Claim 1 wherein the routing instruction packet that the signaling server sends to the client device contains a first routing instruction to send the first data packet to the first gateway node and a second routing instruction to send the second data packet to the second gateway node.

15. The method of Claim 14 wherein each of the first gateway node and the second gateway node has a first address for communication with the client device and a second address for communication within the cloud.

16. The method of Claim 5 wherein the client device transmits the first and second data packets to the first and second gateway nodes, respectively, through a router, the method further comprising providing the first data packet with a first MAC source address and providing the second data packet with a second MAC source address.

17. The method of Claim 1 comprising providing a plurality of signaling servers, wherein the signaling servers divide the task of routing the packets from the client device to the party to be called, and wherein no single signaling server has information describing the entire route of a packet.

18. The method of Claim 1 further comprising concealing the content of at least one of the first data packet and the second data packet using a combination of concealment methods, the concealment methods comprising encryption, scrambling, junk data insertions, splitting and/or mixing and being based on a state.

19. The method of Claim 18 wherein the state comprises a time, a node number, a network identity, or a GPS location.

20. The method of Claim 2 wherein the first physical medium comprises a cellular telephone link modulated using a first carrier frequency and the second physical medium comprises a cellular telephone link modulated using a second carrier frequency.

21. The method of Claim 2 wherein the first physical medium comprises a WiFi channel modulated using a first carrier frequency and the second physical medium comprises a WiFi channel modulated using a second carrier frequency.

22. The method of Claim 7 wherein the first physical medium comprises a cellular telephone link modulated using a first carrier frequency and the second physical medium comprises a cellular telephone link modulated using a second carrier frequency.

23. The method of Claim 7 wherein the first physical medium comprises a WiFi channel modulated using a first carrier frequency and the second physical medium comprises a WiFi channel modulated using a second carrier frequency.

24. The method of Claim 6 further comprising concealing the content of at least one of the first data packet and the second data packet using a combination of concealment methods, the concealment methods comprising encryption, scrambling, junk data insertions, splitting and/or mixing and being based on a state.

25. The method of Claim 24 wherein the state comprises a time, a node number, a network identity, or a GPS location.