[go: up one dir, main page]

WO2018209138A1 - Plate-forme transactionnelle et de télécommunications sécurisée - Google Patents

Plate-forme transactionnelle et de télécommunications sécurisée Download PDF

Info

Publication number
WO2018209138A1
WO2018209138A1 PCT/US2018/032149 US2018032149W WO2018209138A1 WO 2018209138 A1 WO2018209138 A1 WO 2018209138A1 US 2018032149 W US2018032149 W US 2018032149W WO 2018209138 A1 WO2018209138 A1 WO 2018209138A1
Authority
WO
WIPO (PCT)
Prior art keywords
platform
server
content
endpoint
services
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2018/032149
Other languages
English (en)
Inventor
Rolf Herken
Attila Vass
John Harris
Jochen KORNITZKY
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mine Zero GmbH
Original Assignee
Mine Zero GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mine Zero GmbH filed Critical Mine Zero GmbH
Priority to US16/612,357 priority Critical patent/US20200204527A1/en
Publication of WO2018209138A1 publication Critical patent/WO2018209138A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/211—Software architecture within ATMs or in relation to the ATM network
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F9/00—Details other than those peculiar to special kinds or types of apparatus
    • G07F9/006—Details of the software used for the vending machines
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F9/00—Details other than those peculiar to special kinds or types of apparatus
    • G07F9/02—Devices for alarm or indication, e.g. when empty; Advertising arrangements in coin-freed apparatus
    • G07F9/026—Devices for alarm or indication, e.g. when empty; Advertising arrangements in coin-freed apparatus for alarm, monitoring and auditing in vending machines or means for indication, e.g. when empty
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
    • G07G1/00—Cash registers
    • G07G1/0009—Details of the software in the checkout register, electronic cash register [ECR] or point of sale terminal [POS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies

Definitions

  • the present invention relates generally to methods, systems, devices and computer program code products (software) for creating and maintaining a secure telecommunications and transactional platform and network.
  • ZP ZeroPlatfonn
  • Z-Plaiform ZP
  • ZP provides, among other aspects, methods, systems, devices and computer program code products (software) for creating, maintaining and operating a secure, private platform and network for
  • aspects of the invention described herein provide secure and private telecommunications and transactional infrastructures that can be used with and for a wide range of applications, including distribution of data, live and pre-recorded audio/vidco/graphic communications, and online and offline text-based communications and serv ices.
  • aspects, examples, embodiments and practices of the invention, whether in the form of methods, devices, systems or computer program code products (software) will be described in greater detail below, in conjunction with the attached drawing figures. Summary of the Invention
  • the present invention provides methods, systems, devices, and computer software/program code products for establishing, configuring or operating a communications and transactional platform for providing, enabling or supporting secure, private communications and transactions, which may include personal and business communications, whether voice, text, video or other types of communications, and e-commerce transactions.
  • Methods, systems, devices, and computer software/program code products in accordance with the invention are suitable tor implementation or execution in, or in conjunction with, commercially available forms of computer network structures, including servers and other digital processing resources, and devices that communicate with, through or across such structures, such as commercially available forms of cellphones, smartphoncs, tablets and other commercially available telecommunications and computing devices.
  • digital processors can include processing units such as those in known forms of computer network systems, servers, and devices that communicate with such systems and servers, such as cellphones, smartphones. tablets and other commercially available forms of telecommunications and computing devices.
  • the communications platform of the invention comprises: (A) a server comprising a digital processing resource, the digital processing resource comprising a digital processor; and (B) a content transformation module, in communication with the server and interposed between the server and a digital content resource operable to store, deliver or forward digital content.
  • the content transformation module is operable to apply selected content transformations to digital content directed to the server from the digital content resource, and the content transformation module is controllable by the server via a communications channel to selectively request and establish endpoints and users, and to enable selected encryption, on a per-endpoint basis, of content specific to a given digital consumption endpoim, responsive to server-based information representative of endpoint status or endpoint-associatcd user status.
  • the content transformation module is operable to dynamically change encryption parameters for a given endpoint, responsive to the server-based information representative of endpoint status or endpoint-associated user status.
  • the content transformation module is operable to execute selected redirection of content or content requests, on a per-endpoint basis, responsive to the server-based information representative of endpoint status or endpoint-associated user status.
  • the content transformation module is operable to provide selected content transformation, encryption and delivery for applications executing on the server.
  • the content transformation module is operable to provide selected content transformation, encryption and delivery for Web-based services that execute on modules of the communications platform that are in communication with the World-Wide Web.
  • Another aspect of the invention further comprises a communications platform environment supported by the server and the content transformation module and organized into three levels, comprising a core sen ices level, a platform modules level, and a platform applications level, wherein: the core services level comprises core services usable by platform modules or platform applications; the platform modules level comprises platform-based functional modules operable to utilize selected ones of the core services provided by the core services level; and the platform applications level comprises platform-based application programs operable to utilize selected ones of the platform core services or platform modules.
  • the platform is operable to enable a User of the platform to create and maintain a fictional identity (referred to herein as a "Persona") for use on selected venues served by the platform, and wherein Persona information is stored independently from User information, so as to preclude unmasking of a User identity based on corresponding Persona information.
  • a Persona a fictional identity
  • Persona information is stored independently from User information, so as to preclude unmasking of a User identity based on corresponding Persona information.
  • the platform is operable to enable a given User to create separate, different, respective Personas for use with different, respective venues served by the platform.
  • platform-based logical links between a given User identity and a corresponding Persona are established, maintained and protected by a platform-based Identity Translation Service.
  • Another aspect of the invention relates to a method of providing a communications platform for enabling secure, private communications and/or transactions, the method comprising: (A) configuring a server comprising a digital processing resource, the digital processing resource comprising a digital processor; and (B) configuring a content transformation module, in communication with the server, and interposed between the server and a digital content resource operable to store, deliver or forward digital content, the content transformation module being operable to apply selected content transformations to digital content directed to the server from the digital content resource, the content transformation module being controllable by the server via a communications channel to selectively request and establish endpoints and users, and to enable selected encryption, on a per-endpoint basis, of content specific to a given digital consumption endpoint, responsive to server-based information representative of endpoint status or endpoint-associated user status
  • Another aspect of the invention relates to a computer program code product (software) for use with a digital processing system, for enabling the digital processing system to provide a communications platform for enabling secure, private communications and/or transactions, the digital processing system comprising at least one digital processor, the program product comprising digital processor-executable program instructions stored on a non-transitory digital processor-readable medium, which when executed in the digital processor cause the digital processor to: ( A) configure a server comprising a digital processor; and (B) configure a content transformation module, in communication with the server, and interposed between the server and a digital content resource operable to store, deliver or forward digital content, the content transformation module being operable to apply selected content trans formations to digital content directed to the server from the digital content resource, the content transformation module being controllable by the server via a communications channel to selectively request and establish endpoints and users, and to enable selected encryption, on a per-endpoint basis, of content specific to a given digital consumption endpoint, responsive to server-based information representative of endpoint status or endpoint
  • Another aspect of the invention relates to methods, devices, structures and computer program code products (software) for providing, configuring and operating a communications environment or platform for providing, enabling or supporting secure, private transactions, the communications environment or platform comprising: (A) a server comprising a digital processing resource, the digital processing resource comprising a digital processor; and (B) a content transformation module, in communication with the server and interposed between the server and a digital content resource operable to store, deliver or forward digital content, the content transformation module being operable to apply selected content transformations to digital content directed to the server from the digital content resource, the content transformation module being controllable by the server via a communications channel to selectively request and establish endpoints and users, and to enable selected encryption, on a per- endpoint basis, of content specific to a given digital consumption endpoint, responsive to server-based information representative of endpoint status or endpoint-associated user status.
  • FIGS. 1-36 are schematic diagrams depicting exemplary practices of the invention.
  • FIGS. 37A, 37B and 38 are flowcharts depicting exemplary practices of the invention.
  • FIG. 39 is a schematic diagram depicting an exemplary embodiment of the invention.
  • FIG. 40 is a schematic diagram depicting a form of digital cloud configuration in connection with which the invention may be practiced.
  • ZP ZeroPlatform'Or “Z-Platform”
  • ZP Zero-Platform
  • PCT7US 16/22232 filed March 12. 2016, entitled “Transactional Platform " ' (Attorney Docket MNE- 1 12-PCT), which is, along with other commonly owned patent applications listed above, incorporated herein by reference as if set forth herein in its entirety.
  • FIG. 1 is a schematic diagram depicting an overall architecture of the Z-Platform 100 in accordance with exemplary practice of the invention. As described in greater detail below, the Z-Platform architecture is designed so that secure and private applications can be constructed on top of the
  • FIG. 2 is a schematic diagram showing three layers of Z-Platform architecture 100, including Z-Platform Core Services ("ZP Core Services”) layer 1 10, Z-Platform Modules ("ZP-Modules”) layer 120, and Z-Platform Applications (“ZP-Apps”) layer 130.
  • ZP-Modulcs 120 can select from among various Z-Platform Core Services 1 10, while ZP-Apps 130 can select from both Core Services 1 10 and Modules 120. This approach facilitates modularization and maintaining of access control layers.
  • the components of the Z-Platform include the following:
  • ZP Core Services ZP Core Services
  • ZP-Platform Modules (“ZP-Modules") layer 120:
  • ZP-Platfbrm Applications (“ZP-Applications") layer 130:
  • SCC secured and certified connection
  • Z-Platfbrm Core Services can include any of the following, described in greater detail below:
  • Z-Platfonn Modules can include any of the following, described in greater detail below:
  • FIG. 3 is a schematic diagram depicting the security-related design and architecture of an exemplary embodiment of the Z-Platform 100.
  • security is an inherent design objective, and not an afterthought or add-on. Different strength security primitives are combined in order to minimize impact if a ''weakest link" method is compromised.
  • An exemplary practice of the invention has the following characteristics, described in greater detail below:
  • controllable domain controllable domain.
  • - User-level encryption central services are configured 10 be unable to decrypt either realtime or stored data.
  • security will be based in part on an innovative combination of industry standards, known security algorithms and the utilization of proper security practices.
  • Off-line messages are stored in configurable vaults (secure lockers with unique tags and keys).
  • FIG. 4 is a schematic diagram 140 depicting method aspects of securely locating digital keys in accordance with an exemplary practice of the invention. Reference is also made to commonly owned U.S. Provisional Application for Patent Serial No. 62/376210 filed August 17, 2016, entitled
  • - AH client-server communication starts with a /.DNS and a verified entropy exchange; - Devices generate their own keys and get them verified and signed with the platform;
  • AIM Advanced Identity Management
  • Z-Platform Core Services also include Access Control, having the following characteristics, described in greater detail below:
  • the platform in order to tie a real person to its application domain identifier, provides a one-way transformation from Platform User ID to ZP-App Domain ID.
  • ZP-App!icaiions register (submit and get evaluated) for accessing data entries.
  • Data entry access (R/W) is stored in a per-application matrix and also at user/persona entries if application level access needs to be over-ridden.
  • ZP- Applications have their own PKI certificates which they use to validate themselves with Z-P!atfbrm via a certificate chain.
  • ZP-Apps may have their own certificates rooted in the ZP-App certificate signed by the platform.
  • AGS provides managed access (tickct-granring-typc / reservation mechanism) for access controlled data manipulation.
  • Z-Platform Modules :
  • Z-Platform Modules can include A'V Communications Services, which can have the following characteristics, described in greater detail below:
  • the services can be developed "in-house", to eliminate distribution channel dependencies and enable continued innovation and advancement (for example, in areas such a* crypto, and virtual reality (VRj);
  • Z-Sforage Another Z-Platform Module is referred to as Z-$toragc, which can have the following characteristics, described in greater detail below:
  • Message Delivery Another Z-Platform Module is Message Delivery, which can have the following characteristics, described in greater detail below:
  • Unified Message Delivery Service is an advanced "PO-Box / Envelope" type of mailbox system to address message exchanges between personas within or across ZP- Application domains.
  • Fvery envelope has a "stamp” and a delivery schedule, facilitating delivery of approved marketing material, including payed-for and lo-the- recipieni delivery.
  • Payment Connector Another Z-Plattbrm Module is referred to as Payment Connector, which functions to turn internal accounting, such as accounts payable and accounts receivable, into real-world payment transactions, with R.WPI verification.
  • Application Management Services Another Z-Platform Module is Application Management Services, which can have the following characteristics, described in greater detail below:
  • Platform Management Services Another Z-Platform Module is Platform Management Services, which can have the following characteristics, described in greater detail below:
  • Z-Platform Service Classes include the following, described in greater detail below:
  • User Security Access Box utilization secure credential store and retrieval; Establishing User Tunnels;
  • Session Management (session establishment and cryptographic environment); Tokenization Sen ices (utilized by Communication and other external access providing modules).
  • Class III :
  • Part 2 The purpose of Part 2 is to provide a design overview and describe the building blocks of an exemplary practice of the Z-Platform, from both an infrastructure and a software federation point of view, for enabling highly secured communications among platform users and platform applications. Part 2 is organized into the follow sections:
  • AVS Application Gateway Services
  • TLS, TOR and the Z-Platform-provided content transformation is the ability to manipulate the content transmission at a much finer grain— change encryption parameters on the fly, redirect to unauthorized content services (including honeypots or external services if needed), etc.— all subject to (he state of the consumption authority endpoint and-'or user being present on the Z-Platform.
  • Z-Platform provides a user-specific content transformation, encryption and delivery mechanism for both its applications and the traditional web- based services enhanced with its platform modules.
  • Z-Platform For the Applicants, a key factor in designing Z-Platform was the importance of differentiating between anonymity and privacy. Z-Platform "s emphasis is on privacy and the protection of user identifiable information while maintaining total user awareness. Z-Platform is not creating a safe haven for criminals; its primary goal is to protect the communications and the storage/usage of sensitive information of its legitimate users.
  • Z-Platform differs from other communications platforms in a number of ways, including the following:
  • All Z-Platform communications, including attachments, are strictly end-to-end encrypted with enhanced encryption methods. Instead of using a blob storage sen ice, the platform utilizes a tertiary channel for sending attachments and sends the attachment keys through the secondary encrypted channel. For situations where this layered transport is not feasible, Z-Platform offers a secure storage called Z- Lockcr discussed in this document.
  • the aforementioned enhanced encryption methods include aggressive session key rotations that arc synchronized on the secondary encrypted channel. Unlike other derived key-ratcheting solutions the keys are not part of the message.
  • the platform's video calling service utilizes packet shaping (not just packet stuffing), in certain scenarios doing so provides better utilization of the UDP channels as packets are filled to "best-fit" sizes on the given routes.
  • Z-Platform's Audio/Video services provide 1-1 , l-N, and N-N connections with built-in resource sharing (whiteboards, gestures, markers, etc.). They further provide synchronized access controls to these resources thus facilitating real-time manipulation of shared images (zoom, point, annotate) and shared resource distribution (passing the microphone).
  • Z-Platform provides Message Temporal Decoupling services during the server-based message delivery: messages sent via platform servers may have artificial random latencies introduced to reduce timing-related information leakage for sender/receiver events. It is important to note that Z-Platform' s servers only relay messages and are not in possession of any decryption keys.
  • Z-Platform' s design utilizes the encrypted setup session (Signal Protocol type session key distribution mechanism by Open Whisper Systems) to create a channel for setting up a Multiple Participant Diffie-Hellman session with the NCAIET-2015 proposed Key Distribution Protocol. This further strengthens the platform's security channels even in possibly- compromised key situations.
  • Z-Platform utilizes SMP (Socialist Millionaire Protocol) to verify the integrity of the channel (against MITM attacks) and docs not require a visual or audible confirmation of the used keys as most current products do.
  • SMP Socialist Millionaire Protocol
  • the Z-Platform architecture 100 is designed so that secure and private applications can be constructed on top of the Z-Platform.
  • application developers can focus on central value aspects of their applications, while leaving more general tasks to services and functions provided by the
  • FIG. 2 is a schematic diagram showing the major building blocks of the Z-Platform architecture 100, comprising three layers:
  • the Z-Platform Core Services layer 1 10 comprises blocks 11 1 , 112, and 1 13.
  • the Z-Platform Modules layer 120 comprises blocks 121 and 122.
  • the Z-Platform Applications layer comprises blocks 131, 132. 133, and 134.
  • Modules 120 can choose to utilize any of the services 1 10 while apps 130 can and selectively have to utilize any or all of the core serv ices 1 10 and/or module-provided functionalities 120.
  • the Z-Platform Core Services 1 10 include the following:
  • UDMS User and Device Management Services
  • Unified Message Delivery System (UMDS)
  • AMS Application Management Services
  • the Z-Platform Modules 120 include the following:
  • T he Z-Platform Applications 130 include the following:
  • Goal-Specific and Market-Specific Applications utilizing the platform-provided modules and services.
  • the Core Services of the Z-Platform offer a variety of functions to manage users, devices, and endpoints.
  • Z-Platfornvs proprietary subdomain management service culls static access attempts while performing built-in application-specific redirections and access token verification services.
  • the platform's Core Services also provide device management functions, including but not limited to device registration (utilizing a one-way ID transformation), authentication, assignments (both user and application), and usage restrictions.
  • device registration utilizing a one-way ID transformation
  • authentication both user and application
  • usage restrictions When a device first gets registered, it only has access to a limited set of services to enable the user (or the system) to execute proper assignments (certain devices may or may not have access to applications and/or users).
  • Core Services also provide user and persona (sub-user) management, which include but are not limited to identity transformations (application-specific, internal-external representations), device associations, and storage services. All data is segregated and distributed amongst several data stores and are assembled into coherent information at the last possible moment.
  • identity transformations application-specific, internal-external representations
  • device associations device associations
  • storage services All data is segregated and distributed amongst several data stores and are assembled into coherent information at the last possible moment.
  • Platform security functions include but arc not limited to user access verification, application access verification, key management, multi-channel encryption (utilizing both industry standard approaches and specialized content transformation services with rotating parameters), identity translation services (ITS : per-app user ID) and security primitive services such as H.MAC (keyed-Hash Message
  • the Unified Message Delivery System provides a guaranteed application-aware message delivery to the user/persona inboxes. When applications access platform user information services, they arc sent "envelopes" which are addressed to the user within the application domain. This infrastructure is also used to accommodate inter-application communications for a given user without compromising his/her identity.
  • the messaging system can also be configured to introduce random latency to the delivery schedule to avoid delivery time-correlated information leakage. Description of Security-Related Core Procedures:
  • a connecting client 131 exchanges sixteen entropy bytes with the Core Server's Z-Platform Security Center 11 1 during the Entropy
  • FIG. 5 is a table 150 illustrating an exemplary practice of the execution of the Entropy Exchange.
  • the left column 151 lists the steps executed by a client, the right column 153 lists the steps executed by the Z-Platform Core Service, and the middle column 152 lists the messages sent between the client and the Z-Platform Core Service.
  • Z-Platform requires the proper registration of user devices. Z-Platform does not depend on manufacturer/device operating platform-provided identifications for several reasons. It computes its own device IDs, which are essentially 32-byie unique IDs generated from entropy sources and their digests. Upon successful registration a Device Certificate is generated, stored, assigned and communicated back to the device for consequent communications. The registration procedure may be initiated when:
  • FIG. 6 is a table 160 illustrating an exemplary practice of the execution of the Device
  • the left column 161 lists the steps executed by a client
  • the right column 162 lists the steps executed by the Z-Platform Core Service
  • the middle column 163 lists the messages sent between the client and the Z-Platform Core Service.
  • FIG. 7 is a diagram of an exemplary certificate chain 170, comprising four levels:
  • the chain's top level 171 comprises the Root CA certificate 171 ) .
  • the chain's bottom level 174 comprises, for example: client software certificates 1741 , client device certificates 1742, proxy server certificates 1743, user certificates 1744, and other like certificates 174n.
  • the chain's second level 172 comprises intermediate certificates that are positioned in the certificate chain between the Root CA in the first level 171 and the fourth-level certificates 174.
  • the second-level certificates comprise, tor example: Software CA certificates 1721, Client CA certificates 1722, Server CA certificates 1723. User CA certificates 1724, and other like certificates 172n.
  • Some of the second-level certificates 1721 -172n have sub-certificates, which are in the chain's third level 173. These sub-certificates comprise, for example: Client SubCA certificates 1731, User SubCA certificates 1732, and other like SubCA certificates 173n.
  • Issuing individual certificates to every device allows perimeter exclusion of unauthorized clients lest those be malicious or access-revoked devices.
  • devices connect to a server, a traditional TLS connection is established, and both ends verify the validity of the presented certificates. All further communications are handled within this Device Tunnel.
  • User and persona accounts are at the core of the Z-Platform.
  • User accounts have real people with real identities directly associated with them, while persona accounts are different representations of ami are rooted in the user accounts.
  • Personas can also be described as masks that a person (user) might be wearing depending on what venue he/she visits. Its purpose is to protect the original identity under different task-specific and location-specific environments.
  • Persona information is stored independently (both logically and physically.) from the User Accounts and there is no direct link going from Personas to the User. The association and logical linking is done by using Z-Platform's Identity Translation Services (ITS) discussed in a later chapter.
  • ITS Identity Translation Services
  • the transport mechanism or ihc latter Inner Tunnel is similar to a TLS tunnel, i.e.
  • an ephemeral key is negotiated between the client and the server and user/persona-'servicc certifieates arc exchanged and mutually verified.
  • user sessions are not tied to a single network stream (e.g. http/tcp connection) but handled as virtual streams that can last for a longer period of time with periodic rckeying and key rotations.
  • T he current design incorporates a key-ratcheting mechanism ensuring that session messages conform to Z- Platform requirements of achieving perfect forward secrecy (PFS).
  • Registering user and persona accounts utilizing AIM is one of the most involved and complex procedures in the Z-Platform ecosystem from the system's point of view.
  • the registration needs to be verified by taking into account the validity of the used software/platform, location (both physical and IP- space), an initial two-factor authentication and in most cases a valid real-world identity verification utilizing some sort of identification such as a credit card or a linked bank account information.
  • Z-Platform can also generate recovery methods such as Personal Unlocking Keys (PUK.s).
  • PKI.s Personal Unlocking Keys
  • Logging in requires both valid user-entered (user/persona name, some representation of identification such as passwords, gestures, etc.) and device-retrieved information.
  • Advanced Identity Management f AIM Mechanism
  • Z-Platform unlike many other online services, uses an enhanced form of the well-established and eryptographicaHy proven PKI (Public Key infrastructure) and certificate approach for authentication and identity binding.
  • PKI Public Key infrastructure
  • the crucial element in determining a user's and persona * s identity is bound to the fact that the tiser can demonstrate full access to his/her private key that is needed for signing and encrypting messages.
  • the safekeeping of a private key poses a significant problem for most users. Mobile devices are often not backed up and often lost, destroyed or in some cases compromised by accident or through unauthorized events. If they are backed up, the data is usually transferred to cloud storage, utilizing a simple, vendor-chosen form of encryption and storage.
  • Z-Platform uses a system, described in commonly owned patent application Attorney Docket MNE-1 14-PCT incorporated herein by reference, for safekeeping its users' secret keys, which supports the following properties:
  • the secret key is only available unencrypted while it is used for encryption functions on a user owned and controlled device.
  • the secret key is never stored in clear text in any permanent storage, including the designated platform's vaults, secure storage or keychain areas.
  • This unlocking secret may be composed of multiple factors, e.g. the users' name, a passphrasc, a smart card or token, biometric or some form of behavioral input.
  • client device IDs are merged into addressing information needed for locating the stored secrets. T his ensures that the possession of a user's unlocking secret is not sufficient to retrieve the stored secret; the user ' s device also needs to be present.
  • the retrieval parameters are derived from the user's unlocking secret in a way that only a subset of unlocking secret information is sent to the server. This ensures mat on the server side, the actual secret key cannot be decrypted into an accessible font). Deriving the retrieval parameters from the unlocking secret is strengthened by derivation algorithms that allow the user to memorize only short pass phrases (single password access ).
  • the unlocking secrets received from a client arc only held on the server in memory while needed for ongoing computations; they are securely purged immediately after usage. This ensures that the relations between the servers' databases can only be traced while the transient secrets received from the users are present.
  • the physical storage of the encrypted secret keys are in an unmarked form, i.e., the key materials an? not marked with any identification but are mass-stored in a blob store with random bytes filling gaps between them.
  • Z-Platform uses a linked access mechanism where each lookup stage gives a pointer to the next stage with no need to validate the correctness of the target link or the content of the data stored at the addressed locations.
  • This deliberate design was added to severely limit rejection-based access attempts.
  • the general approach for this mechanism is rooted in the locker box access design similar to the platform's Z-Locker data storage solution discussed in a later chapter.
  • the user-provided and device-provided information are combined to generate an entry address and access parameters.
  • the entry locker Reference Box, RcfBox, addressed by the entry address
  • enough information is retrieved to compute the actual Security Box (SecBox) where the user's private information is stored.
  • the user's Z- Platforra ID is stored along with other identifying elements, such as the length and the reference
  • the actual encrypted private key is stored in another location from which it is retrieved by providing the block:offsef pair and the length (encrypted key length).
  • H is important to note that the retrieval mechanism has no notion of valid entries, it simply returns a data block defined by the block .offset: length triad from certified and verified servers. It is also important to note that all access requests return data to the requesting entities without validation. Validation of returned data is done on the client side and is heavily context dependent. This is a deliberate behavior resulting from our policies on not having platform access to private keys.
  • the Identity Management is split into two levels; Ixvel Zero only addresses access control to users' Security Boxes and Session Management, while Level One validates the users' entities utilizing the RWP (Real -World-Person) and KYC (Know-Your-Customer) links. The latter is further explained in the Know-Your-Customer Connector Service Module description.
  • RWP Real -World-Person
  • KYC Know-Your-Customer Connector Service Module description.
  • Z- Platform also has its own RWP identification mechanisms (such as through its Payment Connector Services and Behavior Observations)
  • combining a third-party's KYC service further enhances the platform's identifications of its real users and may also provide a verification link back to the third party's KYC services further strengthening ii.
  • FIG. 8 provides a tabic 180 setting forth a number of abbreviations and expressions (i.e., parameters) are used in the present description.
  • Table 180 comprises the following columns: Parameter (column 1 ) 181 ; Computation (column 2) 182; and Usage (column 3) 183.
  • FIG. 4 is a diagram providing an overview of the components of an exemplary system 140 used by Z-Platform for safekeeping its users * secret keys. As mentioned above, system 140 is described in greater detail in a co-pending patent application.
  • Device generates a random DcviccID (or uses a previously generated and stored value from the device's secure storage).
  • Device generates a random private/public key pair.
  • Device generates a random user/persona UUID.
  • CSR certificate signing request
  • Server checks if UUID (from CSR) is unique.
  • Server signs CSR and stores signed certificate in public certificate table.
  • Server stores REF and Saltitn-K x SEC2 in Re (Box at location LOC.
  • Server stores EncryptedPrivateKey in SecBox at location REF x SEC I .
  • Server retrieves RetBox item from location LOC ' . reads REF, UUID and SaltUn-K x SEC2.
  • Server retrieves EncryptedPrivatcKey from SecBox at location REF x SECI .
  • Server retrieves signed certificate from public certificate storage.
  • the procedure requires the user to be fully authenticated for the account.
  • the procedure also requires that the Device ID of the new device be temporarily shared with the existing device, a functionality that is implemented using visual pictograms (like QR codes) or preferably an NF/BT (Near- Ficld/Bluctooth) communication. The latter necessitates physical proximity of the two devices which is construed as an added security measure.
  • a pseudo-recovery device can be created. While Device IDs are normally not accessible for the users (generated by the device from device unique properties and random data), a recovery Device ID may be shared with die user for safekeeping. Users can opt out of providing recovery devices.
  • Client obtains the new device's DevicelD (from QR Code or NF/BT channel).
  • Device sends LOC-old, SEC I -old, LOC-ncw.
  • SEC I -new, Saliitn-K x SEC2-ncw to Server, requesting a new device be authorized. This request is encrypted and signed with the private key.
  • Server decrypts with public key and checks if the request signature is correct.
  • Server checks if LOC-old points to a valid RelBox and if the UUID x SEC 1 -old matches the
  • Server stores REF-new x SEC 1 -new and Saltitn-K x SEC2 in RcfBox-new at location LOC- new.
  • This action can only proceed from an already active and registered device.
  • the device non-cxclusivcly gets associated with the user
  • All User and Persona communications are encrypted (inside the device tunnel) with individually negotiated encryption keys. To allow for the encryption to be established before messages to create or use user accounts are exchanged, the session is created initially without any specific authentication in place.
  • a session can have several states: NEW (no keys exchanged yet), OPEN (session encryption set up, but no authentication yet), AUTHENTICATED ⁇ the client's identity has been verified), EXPIRED (session needs renewal).
  • FIG. 9 provides a table 190 setting forth the execution of this process, comprising the following columns Client H>1. Message 192. and Z-Plaiform Core Service 193.
  • client and serv er share a secret and a session ID.
  • the session ID makes it easy to refer to a specific session secret which is used to encrypt the subsequent messages.
  • the UserAuthRequest(Create) creates a new user/persona identity.
  • FIG. 10 provides a table 200 setting forth the execution of this process, comprising the following columns: Client 201 , Message 202, and Z-Platform Core Service 203.
  • FIG. 11 provides a table 210 setting forth the execution of this process, comprising the following columns: Client 21 1, Message 212, and Z-Platfbrm Core Service 213.
  • FIG. 12 provides a table 220 setting forth the execution of this process, comprising the following columns: Client 221 , Message 222, and Z-Platform Core Service 223.
  • Persona accounts arc very similar to user accounts from the Z-Platform's point of view. Creating and using persona accounts are tied to Z-Platform Applications (ZP-App) though. As persona accounts are ZP-App representations of Z-Platform users inside a ZP-App subsystem, they arc mainly handled by the specific ZP-App-related services. Z-Platform Core Services are only responsible for storing the user/ZP-App/Persona associations for a given user. This is executed in an obfuscated fashion utilizing the platform's Identity Translation Service (ITS).
  • ITS Identity Translation Service
  • the client app authenticates the user via the Z-Platform Core Services.
  • PCT Persona Creation Token
  • ZP-App Service stores the PCT and associated ITS user identity.
  • Client invokes a new user creation process with Z-Platform Core Services.
  • Client registers the new UUID utilizing the PCT with the ZP-App Service.
  • Client sends a persona-user association request to Z-Platform Core Services with the UUlDs and PCT.
  • Z-Platform validates the request with the ZP-App Service and if the PCT/UUiDs match, it associates the persona UUILVZP-App ID with the user.
  • Persona account retrieval and initialization are executed by specific ZP-App clients in order to validate with specific ZP-App services. All persona logins start with logging in to the Z-Platform as a user. From there, the client can request the associated persona identifiers (ITS) and can proceed to logging in the pcrsonas with the Z-Platform Core Services, similar to the user login process.
  • ITS persona identifiers
  • Credential recovery is a deliberately complex procedure on the Z-Platform. This is to enhance the security of keeping the platform users' ⁇ (Personally Identifiable Information) safe. If a user loses all his/her devices, forgets his/her passwords or user name, he/she is considered compromised from the system's point of view.
  • a PIN Unlock Key (PUK) is generated for all accounts and an associated recovery RefBox is created.
  • the PUK is then encrypted with a randomly created symmetric key and this key is deposited with the Payment Services.
  • the resulting PUK is a long string and may be commiinicated to the user in various forms; QR codes or a textual representation during account creation time. If a user knows his/her user name, password and can identify himsellihcrsclf with the Payment Services (hosted by the platform holder or its payment provider partner) it is possible to find the SecBox by utilizing the PUK
  • a recovery email account was associated with the Z-Platform user account, it will aid in the recovery procedures. If a verification email was also associated with the user account, it will be utilized for 2 or 3-factor authentications. The low-level details of the correct design are currently in progress.
  • Finding the Reference Box based on PUK and username/password combination is as follows:
  • Device computes parameters from unlocking secrets: SEC I , SEC2, LOC, but instead of using "Device” it uses the PUK.
  • Z- Platform's Core Services can provide store very limited amounts of information, mostly transformed references to other access-controlled information such as Real- World Person References (to store the user's real name, pictures, and other personally identifiable information). Payment Credentials, Platform Preferences (language, payment preferences, Do-Not-Disturb settings).
  • Z-PJatform Core Services also store with the platform user accounts an ITS transformed Persona UUID list for every authorized ZP-App and an associated access matrix which describes which ZP-App may have access to which parts of the stored information.
  • IAM Information Access Matrix
  • AH ZP-Apps have their registered lAMs stored in die approved application repository in the form of
  • field names are not literal references to the actual field descriptors, rather they use a short form validated SIIA3-224 hash created from the field reference names. This not only serves as an acceleration method but also introduces another layer of transformation to the application access matrix.
  • Z-Platform provides a walled garden approach for other services and offerings built on top of it. All Z-Platform Applications (ZP-Apps) have to be authorized by the operating entity before they can use the platform services.
  • ZP-App client connects to the Z-Platform, it first establishes a device tunnel as described in the previous chapters, than identifies itself with its ZP-App ID as a first filter mechanism. If the ZP-App client can prove application identity, it can proceed to user authentication. Once a user is authenticated with the platform, it is considered privileged to use the other services provided inside the ecosystem.
  • a ZP-App in development is Zeitmarket. It utilizes Z-Platform ⁇ s user and persona management core services and the provided platform modules. The platform is open for other third-party applications. The detailed process for approved vendors and ZP-Applications to set up a platform service is discussed in the descriptions below of Z-Platform Application Gateway Services.
  • ZP- Apps application systems running inside the Z-Platform Ecosystem
  • ZP-App domain IDs once proper access has been granted
  • Z-Platform login process applies to both user accounts and the used ZP-App account.
  • the IDs are then used to contact other users, and they arc stored in the ZP-App-spccific contact lists.
  • This level of abstraction protects against matching ZP-App IDs to Z-Platform users (real people) in case a ZP-App (or even if the Z-Platform) databases arc compromised. There is no information leakage between the ZP-App and the Z-Platform user identifications, nor between different ZP-App domains.
  • the ITS-related translation mechanism is a combination of database lookups and mathematical formulas.
  • the first parameter in the ITS HM.AC algorithm comes from a distributed ZP-App domain key- pair database, the second parameter is the result of a one-way HMAC operation on the Z-Platform unique ID using ZP-App domain parameters:
  • Unified Message Delivery System (UMDS)
  • Z-Plaiform's HMDS is a centralized and precision tuned mailbox system that facilitates message exchanges among users/personas/applications. It was modeled after the standard postal services utilizing PO Boxes, in a sense that every message is interpreted as a letter or a parcel, which has the usual attributes of senders and intended recipients, but they also contain extra information in the form of "Postage Stamps" (every message is interpreted as a business transaction, whether that be standard fee- based delivery, free-shipping, collect-on-delivery or bulk mail), Certified/Registered Mail (a unique entry is created in the B! log about the timing and the route it takes), Delivery and Signature Confirmation (a message is sent back when the recipient receives or reads the message). Delivery Scheduling (when and under what circumstances the mail should be delivered, such as marketing materials) and a complex Delivery Authorization to enabled selective filtering of messages based on senders and/or messaging patterns (such as simple time-based SPAM filtering or user configured rules).
  • the actual message is not stored within mailboxes, but in a PO Box, allocated from Z-Platform's UMDS services.
  • the allocated ("rented") PO Box ID is stored with the User/Persona Information during User/Persona creation time PO Boxes store small-footprint messages directly, larger ones follow the "parcel notification" approach: when a message is generated, it is tagged with the delivery information (ZP-App-lD and Per-App-Pcrsona-iD. Delivery Parameters) while the actual message gets encrypted with a generated symmetric key, it gets a unique ID associated and is then stored within the UMDS storage facilities, utilizing a Z-Shclf or Z- Locker solution.
  • the key and the unique ID get added to the Delivery Parameters with a X509 v.3 encapsulation (using the public key of the addressee) guaranteeing total privacy and protection of both message and delivery notifications independently.
  • AVS Application Gateway Services
  • the Z-Platform ecosystem provides opportunities for ZP-Application developers to access a host of services and shares similarities with other social platforms.
  • Z-Platform * s Application Gateway Service provides a variety of tools for developers to register, configure, market, and maintain their externally (or internally ) hosted applications and makes it simple to ensure privacy and security is maintained for their Z-Platform users.
  • the Platform Application Gateway Service ensures data is exchanged only between consenting parties, utilizing amongst other mechanisms the information access matrices.
  • ZP-APPs Registered and verified third party applications
  • ZP-APP-1D Registered and verified third party applications
  • Signed Application Certificates These 2 data blocks are included in the client applications and are necessary to establish connections with the Z-Platform services.
  • the application ID and the corresponding certificate which has the ID embedded
  • Critical info Application Name, Description, Category, etc.
  • App Privacy Configure app as private or publicly listed.
  • App Security Configure additional security measures (e.g. Originating IP/Subnet range)
  • Every app receives a unique identifier by which it will be identified internally.
  • a. API access is dependent upon proper presentation of registration credentials while reserving platform resources through the Gateway API.
  • Owners may create, refresh, or revoke an app's API credentials at their discretion.
  • App Marketplaces OS/Device Platform
  • the consent wording informs data subjects in a transparent and easy-to-understand manner about the relevant data processing activities.
  • the platform In order to make a clear distinction between satisfying the data privacy requirements of regulatory institutions and implications of the platform-specific privacy measures (Personas, ZP-App-specific Person IDs), the platform generates the consent form language.
  • ihcy Once a user opts in to ihc app's data requirements, ihcy go through the registration process discussed earlier where a ZP-App-spceific Persona gets created and associated with the Z-Platform User and this new Persona gets "registered" with the third-party ZP-App.
  • a ZP-App changes permission requirements, or as Z-Platform privacy changes dictate, users may be required to update their consent by resubmitting the permissions approval form.
  • the form builder also generates a list of salient changes and employs specific styles/colors to highlight revised portions of the form.
  • the ZP-App ecosystem translates global internal user/persona IDs to app- speciftc IDs utilizing the ITS mechanism. They do not follow an application user from app to app, and are unique to each app they join.
  • the Application Gateway Services provide endpoints for obtaining access to platform resources. There are various reservation types; however, most will fall into either of the following two categories:
  • the reservations API will first require the persona to be registered with the third-party application making the request (scrver-to-server). i.e., present in the ITS database.
  • the application completes a request for user data and, provided all permissions are in place, the API returns a reservation for the user's data updates via the User and Device Management Services.
  • Reservations may also provide a specific host for handling subsequent requests on this reservation.
  • reservations confirmation middleware agent acts as both authentication middleware and a reverse proxy, it prevents web servers from having to Held resource requests from obviously unverified/invalid sources. This confirmation process will forward properly-reserved resource requests to their internal resource providers.
  • the reservation service is consulted on:
  • the confirmation agent checks the reservation store of the service it represents for a valid reservation.
  • the agent forwards the request on to the appropriate service API.
  • the endpoint handler and API security modules perform a complex set of functions while proxy ing the external requests:
  • TLS is terminated, request bodies are sanitized for delivery to downstream services.
  • Validated reservations are added to the request headers for possible later confirmation and potential contract association.
  • the reservation's TTL may be extended as subsequent requests are completed.
  • gateway services web front-end Developer registration and all actions associated with application setup/configuration are provided by the gateway services web front-end. AH reservation-related API requests are handled by the gateway services json.api. Internally, the gateway services front layer is load balanced and expandable. Each front layer app accesses:
  • FIG. 13 is a diagram providing an overview of an exemplary system 230 according to an aspect of the invention that implements the above, depicting extemal-hosted platform apps 231 and an internal platform 232.
  • the internal platform 232 includes a gateway services module 233 with a gateway app front layer 234 that accesses modules used for application setup/configuration, including: an app registration configuration store module 235a, a user and app access matrices module 235b, and a reservation store module 235c.
  • Load balancing is provided by a gateway service load-balancing module 236.
  • Subsequent requests are processed using a user services API module 237, a reservation confirmation middleware module 23S, and a user services baekend module 239.
  • Z-Plafform Modules arc logical units of services (with both back-end and tang-end components) which arc not considered to be pan of the core serv ices, but can provide valuable services to the
  • the Audio/Visual Communication Services module provides a fully featured communication service to the integrating applications. A-'V sessions are handled as contracts with negotiated
  • Two or more users can be connected in an audio/video session, which includes adaptive bandwidth transmissions, geo-awarc routing and bridged connections with all these having the ability to optimize not only for fastest delivery, but to increase routing complexity (to interfere with tracking ).
  • a custom channel is also provided, which enables file/document sharing, shared desktops and shared gestures. T he stages and states of the communication sessions are closely observed and tracked (but not the content?) in order to provide immediate conflict resolution and/or contract renegotiations in case of quality problems. This feature is also essential in providing prioritized sessions to paying/free services. All communications are encrypted with session keys, which the participants negotiate after successful initial connection (which was encrypted with system-provided communication keys). This ensures that the Z-Platform Core Serv ices have absolutely no access to the content of the communication. The session keys can be rotated and renegotiated on-the-fly. out-of-band as well, further strengthening the platform security services.
  • Z- Store is Z-Platform's secure olT-site/on-site storage solution.
  • Z-Lockers are identified by reference identifiers (textual representation) and are opened/closed with passphrases (user assigned text, bitmap, sound, etc.) and PJNs (system assigned). The actual location of a locker is generated from all three information sources through the combination of one-way
  • the associated symmetric encryption key (currently 512 bits long) is also derived utilizing all three information sources, thus both finding the location and acquiring the decryption key requires proper access to all the different domain sources.
  • Z-Shelf provides a simpler access mechanism for deposited data, similar to known "blob-store" services.
  • the Platform Management Service (PMS) module is responsible for handling device, user and application access management. This includes granting and revoking access to different actors to/from different services and is responsible for renewing/renegotiating certificates, and providing basic key management services.
  • PMS Platform Management Service
  • the Application Management Service (AMS) module is responsible for ZP-App registrations and the associated account managements.
  • ZP-App developers utilize the interface provided by AMS for requesting changes and approvals from the Z-Platform ZP-App Account Managers.
  • PCS Payment Connector Services
  • KYCCS Know- Your-Customcr Connector Services
  • the Platform Mail Delivery Service (PMDS) module provides individualized and logically detached message delivery services within a given ZP-App. further limiting any unforeseen platform contamination and information leakage.
  • Z -Platform's UMDS provides a global message delivery within the Z-Platform members. Audio/Visual Communication Service Module
  • Z-Platform provides its own real-time Audio/Visual services. These come in the form of ' * Video Sessions", “Voice Sessions” and standard messaging services (real-time and stored, instant messaging chat type).
  • This real-time service uses adaptive bandwidth and stream shaping techniques to guarantee acceptable communications even in low quality network environments such as cellular networks. All communications follow the client-servcr-client topology with parts of the messages encrypted for the platform services (these are strictly traffic and routing-related information), while an internal cliem-to-rodnt encryption tunnel (with DM negotiated keys and rotating schedules) provides complete assurance of the service provider's inability to decrypt the messages flow ing between the participants.
  • s communication server components are comprised of a network of Communication Controllers (CommCtrl) and Communication Nodes (CommNode).
  • the CommNodes relay media packets between clients and act as a central point of control for communication sessions. In a special bridging mode, the CommNodes may be linked together to provide better communication experience if participants have difficulties connecting to a single node.
  • CommCtrl drives the entire communication system. It handles requests from the platform's Core Services for creating communication sessions between participants, it tracks CommNode statuses and routes sessions to optimal nodes.
  • CommCtrl also provides central record keepings in a unique style, utilizing contracts.
  • Z-Platform provides its personas the ability to communicate over secured streaming sessions in real-time through its Communication Infrastructure. T he process for establishing and executing communication sessions between Personas is similar to a standard contract-based approach. When a Persona contacts the Communication Service Core with the intention of starting a session with another Persona or Personas, a contract is created for defining and monitoring the serv ice-level agreements among all platform resources involved. Beyond the basic tracking of connection quality and
  • contracted sessions may underlie other billable services. These contracts allow the Communication Service Core to provide the accounting basis for premium and/or billable sessions built upon the Z-Platform.
  • the Communication Service Core (CommCore) is the contact entity within the Z-Platform infrastructure in charge of handling the Persona ⁇ s request to connect with other Personas and organizing the necessary communication infrastructure to execute successful communication sessions. It also acts as a de facto representative of the Persona; handling accounting-related tasks, negotiating quality of services, and resolving conflicts that may arise while providing the service itself. In general, Personas only contact the Communication Service Core directly when they experience issues with the communication service.
  • the client-side routines automatically keep the CommCore apprised of communication service events, performance statistics, and connectivity issues related to the active running contract. This mechanism provides part of the required feedbacks used to evaluate service quality and contract fulfillment.
  • the Communication Service Core accepts the request (user validations, presence determinations), it draws up a contract and asks the Communication Control Center (CommCtrl) to evaluate it for the requested communication session.
  • This latter service can be interpreted as a service providing agency, which has contractors who do the work (Communication Service Nodes aka CommNodes) and it also manages the contracts, keeps a tab on the contracted work and does reporting and record keeping.
  • the Communication Control Center evaluates the needs of the clients (QoS requirements, class-of service required), it identifies the best worker (or workers, if bridging service is required) to execute the contract and contacts the candidate worker.
  • the worker service (Communication Service Node) evaluates its curreni condition and either signs the contract or rejects ii. If the contract is rejected, the Communication Control Center identifies another worker who is best suited to replace the previous candidate.
  • Contracts fulfilled by the Communication Control Center track all requests and work related to servicing a specific communication session across both client* ami server-side resources. As this service is built on top of several disparate systems with perhaps- limited connectivity beyond the control of the Z-Platform, contract accounting identifies potential gaps between the system's efforts delivering the service and the Persona's experience of it
  • the Communication Control Center returns the signed contract to the Communication Service Core for final evaluation. There is some level of autonomy in this process, but user intervention and/or agreement may need to be secured before the Communication Service Core "signs" the contract. Once the contract is accepted and signed by all parties, it gets filed under the "active contracts" folder with the Communication Service Core, a copy is furnished to the Communication Control Center and the necessary keys and locations are exchanged. Since these services arc implemented on top of a range of third-party infrastructures (telecommunication 3G/4G'LTfr75G.
  • Z-Platform's contract management provides a solution for handling conflict management that arise from the nature of combining these heterogeneous systems into a quality product experience. Clients are equipped to alert their representative (Communication Service Core) should session quality degradation or drop occur.
  • Communication Service Core Communication Service Core
  • the Communication Service Core then remedies the situation with the session participants.
  • a detailed report (diagnostic information) from the Communication Service Node is stored with the contract and the decisions of the Communication Control Center are weighed against the session's reported quality and performance statistics.
  • Communication Control Center is able to continuously improve how it provides secured real-time sessions to a multitude of users.
  • FIG. 14 is a diagram demonstrating an exemplary practice of the contract negotiation system
  • FIG. 15 is a table 250, identifying for each process step (listed in column 251) the entitles involved (cohunn 252), the contract goal inside Z-Platform (column 253), and the corresponding analog word contract goal (column 254).
  • CommClieni (Persona) initiates a call request to a specific target persona from its contact list, which contains external IDs only.
  • CommClicnt sends TxJD communication request to CommCore using persona-encrypted channel.
  • CommCore requests a new communication session (ZmComSession) from CommCtrl:
  • CommCore generates a CommRcquestToken (PFS) for the CommCtrl response.
  • PFS CommRcquestToken
  • CommCore gathers SxlD, TxlD, Kroom, QoS parameters for the xID.
  • CommCore assembles the request packet.
  • CommCtrl receives request from CommCore and sets up a session internally:
  • CSession Generates an internal structure (CSession) and stores Kroom, CommRcquestToken and xlDs.
  • b. Generates a crID (ContractlD) and stores in CSession. This will identify this session.
  • c. Determines best hosting node configuration (NodcJD or NodclDs if bridging is
  • cIDs communication ID
  • PFS CommControlToken
  • g. Generates a symmetric key of KCCTRL and stores it in CScssion.
  • CommCtrl requests a new session (virtual room) from the identified CoramNodc(s) and sends over crID, NodcRe ⁇ iucsiToken, elDs and Kroom.
  • CommNode allocates the virtual room (CommNodeSessioniD), registers the expected participants (cIDs), crID and the Kroom. Sends back the CommNodeSessioniD, ZmNodeURl and
  • CommCtrl verifies if sent back NodeRequestToken is valid and adds CommNodeSessioniD and ZrnNodcURI(s) to CScssion if so.
  • CommCtrl sends respond back to CommCore using the CommRcquestToken and sends back xlDs. cIDs. KCC TRL, CommControlTokens, ZmNodeURl(s), CommNodeSessionlD(s) and crID.
  • CommCore checks if CommRequesiToken is valid, if so, it generates a symmetric key to be used for encrypting the initial setups, called KCONT. CommCore then prepares packages for each CommClicnt containing Kroom, KCCTRL. KCONT, cf D, CommControlToken, ZmNodeURl, CommNodeSessioniD. These packages get encrypted in a PKCS7 format with the CommClicnt" s public key.
  • ComraClient receives the package, decrypts with the private key. It encrypts its CommControlToken with KCCTRL, encrypts the encrypted CoramControlTokcn and the clD with Kroom, adds
  • CommNode identifies target session ("the room") on CommNodeSessioniD, it decrypts clD and
  • CommNode sends the CommNodeSessioniD associated erf D. CommNodeSessioniD, clD and I ControlToken JKcctrl to CommCtrl for verification.
  • CommCtrl decrypts ConfrolToken with KCCTRL found for the given crID if CommNodeSessioniD matches and clD is present. Checks if the ControlToken is valid for the clD. IF valid, it looks up xlD for the clD. CommCtrl connects to CommCore with request to check if xlD is active for the
  • CommCore verifies if ilD (derived from xlD) has an active session and verifies if the crID and CommNodeSessioniD is active for the given ilD. If OK, it responds back with "Client verified" to CommCtrl.
  • CommNode enables CommClient to join the session.
  • CommCtrl updates its CScssion to reflect the status change.
  • ComraCliem uses KCONT to encrypt payloads to be forwarded to the other CommClicniis) via CommNode, as CommNode does not possess KCONT.
  • CommClients execute a Diffic-Hellman key negotiation/exchange using the KCONT channel to establish a new session key.
  • the new symmetric key negotiation described in Operation #23 can be executed periodically during a live session (parameters are influenced by settings) and the key -swapping/key-switch is executed and synchronized via the auxiliary stream control channels.
  • FIG. 16 is a table 260 illustrating the storage of data on participating service blocks, in FIG. 16, an italic font is used to indicate variables/parameters received and stored. A bold font is used to indicate variables/parameters generated and stored. A plus sign ( * ) indicates used-once variables/parameters, which get deleted after use. These variables are used to guarantee perfect forward secrecy.
  • FIG. 17 is a table 270 setting forth abbreviations used for the communication setup.
  • the CommNode component is a server application written in cross-platform that can be deployed on Linux, MacOS or Windows based systems. CommNode instances can be deployed in regions optimal for active clients. They are relatively lightweight and because they maintain little state. require only a small amount of memory. Bandwidth consumption depends on the number of connected clients and the quantity and type of streams they publish. The primary responsibilities of the
  • Packet forwarding a single CommNode manages multiple sessions, each with a variable number of participants.
  • the CommNode forwards media packets from stream publishers to session participants. End-to-end encryption prevents CommNodes from accessing media content.
  • CommNodes provide cooperative QoS management by balancing the bandwidth usage of all active streams in a session. Streams are prioritized based on their type (e.g., audio is given higher priority over video) and CommNodes manage rate control, instructing clients to raise or lower bitrates based on network segment transmission quality. All client-node and node-client spokes have network quality tracked and measured independently to provide input to the QoS algorithm.
  • Session management CommCtrl requests the creation of sessions with a given set of participants.
  • the client component communicates directly with its assigned CommNode to allow a participant to join a session and this interaction in managed by the CommNode throughout the session.
  • CommNodes report participant status (who has joined and who has left as well as other notable events) to CommCtrl, which persists relevant information.
  • Track packet reception for reliable channels CommNodes receive acknowledgement* (ACKs) from session participants for reliable media streams. These are tracked and combined at the CommNodcs to reduce ACK traffic to stream publishers. From the point of view of the stream publishing client, there is just a single receiver.
  • this feature provides a mechanism for client applications to restrict access to shared resources. Session participants can acquire these named locks with ownership status broadcast to remaining participants, greatly simplifying application logic. They can be used, for example, for a session participant to control a presentation component (e.g., pan and zoom a shared image or take control of a virtual microphone) and later release that control making it available to other participants.
  • a presentation component e.g., pan and zoom a shared image or take control of a virtual microphone
  • Each CommNode uses a single UDP socket for most incoming and outgoing traffic.
  • CommNodcs accept TCP connections from clients to begin the session joining process, but this connection is closed once a client is accepted into the session and the remainder of the session communication takes place over UDP.
  • CommNodcs also communicate to CommCtrl over a separate connection, which utilizes; Zcro.MQ, a high-performance asynchronous messaging library.
  • Communication Client Component is a library that can be integrated into a larger application. Its implementation has two distinct pieces, a core component that is cross- platform and a platform-specific component that is not:
  • the CommClient core is written in cross platform C++ and provides the majority of functionality for the CommClient component, it interfaces with the network layer and manages sending and receiving of media packets as well as communication with CommNodcs.
  • Communication is packet-based with streams (audio, video and otherwise) segmented into packets for network transport. This allows for the flexibility to use either TCP or UDP sockets for communication with the CommNodcs.
  • packets Upon packet reception, packets are demuxed into independent media streams, which arc grouped according to the stream publisher participant. Packets are fed into a jitter buffer and playout queue, which reconstructs the original stream liming and determines an appropriate playout delay.
  • the goal for most media streams is to minimize latency while still assuring the stream can be decoded without gaps. Data block transfers generally do not have the same low-latency requirement.
  • CommClient core utilizes the Opus codec, implemented with a cross-platform library
  • Opus provides forward error correction (FEC) to seamlessly cover single-packet gaps in the audio stream.
  • FEC forward error correction
  • FEC forward error correction
  • Silent audio frames and their corresponding video frames are treated like scene boundaries.
  • the audio is silent and skipped, its video is replaced by a generated transition effect that gives a receiving participant a visual hint of what transpired during the silence.
  • CommC'lient's core component funnels all outgoing media packets through a send queue, which prioritizes packeis as well as provides rate control for data transfers.
  • All outgoing media packets are sent to the client's associated CommNode via a single UDP socket (however nothing in the send queue implementation would prevent transporting over TCP in the future).
  • the send queue handles packciization of media data - both audio and video as well as data transfers. Packetizarion occurs incrementally just before a packet is sent. 1.e., fragments of media data arc partitioned from a larger block to fill available packet space, which allows for variable packet sizes Z-Platform's A/V Communication packet format (further described in later sections) also allows mixing of audio, video, and generic data in a single packet. So for example, in the case of an audio frame (which may only be a few dozen bytes) other data types can fill out the packet if available. Otherwise packets will be padded to a minimum size for effective encryption and transmission.
  • the send queue prioritizes media data based on its type. Audio data is given priority followed by video. Data transfers, which generally don't have the same low-latency requirement, are given lower priority, unless a specific requirement is in place for prioritized data delivery. Data transfers themselves are also split further into priority levels.
  • a smaller portion of CommClient is implemented in a platform-specific manner and provides a uniform interface to the varying device hardware and OS-specific services.
  • the primary service used by CommClient and provided by the device's OS is the H .264 video codec.
  • Rate control for video is provided by the encoder, which is used in a variable bit-rate mode.
  • Image resolution and frame rate can also be dynamically adjusted based on bandwidth and quality requirements.
  • CommClient currently supports the following device/OS platforms:
  • Z-Platform's A/V Communication Services utilize a custom packet format for all communication between CommNodes and CommOients as well as several custom PJUDP protocols where reliable transport is required.
  • T he Communication Services implementation includes a set of cross platform C++ classes to support this format/protocols, which is shared between client and CommNode components.
  • All packets exchanged between ComraClicms and CommNodes begin with a fixed length header. This header is not encrypted, but carries no personal identifiable or otherwise sensitive information, it begins with the session token, which is a randomly generated 32-bit value that allows the CommNode to route the packet. Each participant in a session gets a unique session token. Only the CommNode knows the mapping of session tokens to actual sessions so it cannot be used by a third party to determine which users are communicating with one another.
  • Control Packets There are two mam types of Communication Service packets: Control Packets and Media
  • a packet is logically divided into sections referred to as "pockets".
  • a Communication Service media packet is comprised of one or more pockets.
  • Control packets which are used to exchange commands and other information between CommNodes and CommCl tents are not formally divided in this way (although in some cases may contain variable length lists).
  • media packets Following the common header portion of a packet, media packets include a variable number of pocket headers (up to 32 pockets per packet). Pocket headers are also unencrypted, but carry no sensitive information.
  • a typical pocket header contains:
  • Timestamps arc unsigned 32-bit integer values that represent ticks relative to the session clock.
  • the session clock is set to 4 «S () 00 ticks per second.
  • Modulo arithmetic is used to compare timestamps to account for wraps across the 32-bit boundary.
  • Stream ID unique ID within the session that identities the stream.
  • Sequence number monotonically increasing and contiguous sequence of unsigned integers. They are 16 bits in size, but expanded to 32 bits by receivers, which track the number of wraps across the 16-bit boundary.
  • Pocket payfoad size each pocket can have a variable sized payload.
  • the remainder of the packet following this variable length header contains pocket payloads.
  • the payload portion is always encrypted with the content key and is therefore not readable by CommNodes.
  • All pockets are encrypted as single blocks. They arc padded with a minimum of 18 random bytes, but padded with additional random bytes as necessary to meet a minimum size of 64 bytes and alignment to a 32-byte boundary.
  • the video and audio contained in a given packet may, but need not. correspond to the same time interval. If they do, and if they usually arrive in order, then streaming the session may be especially efficient.
  • Z-Platfornvs A/V Communication Services utilize three custom RUDP protocols to provide reliability over a UDP socket connection, each customized to a particular set of needs and requirements. Note that although packet loss obviously occurs at the packet level, reliability is applied per pocket rather than per packet. In other words, if a packet is lost which contains a mixture of pockets containing both reliable and unreliable data, only the pockets marked as reliable will be recovered.
  • CommClient immediately after a CommClient successfully joins a communication session (which takes place over a TCP connection), the CommClient switches to UDP for subsequent communication with its CommNode and closes the TCP socket.
  • Some commands typically ones that are cyclic in nature, do not have a reliability requirement. For example heartbeat commands are sent at regular intervals and can endure a reasonable amount of packet loss.
  • CommClient also send regular stream reports, which describe packet loss on the CommNode to the client portion of the network segment. A lost stream report has negligible impact since a report quickly becomes stale and is updated by a subsequent report.
  • a custom RUDP protocol is used to gxiarantec delivery. This protocol is designed with the assumption that these commands carry a relatively small payload. but require timely delivery. Another assumption is that these commands arc sent sparsely as opposed to a continuous stream of data.
  • An example of a command using this RUDP version is the command to request a video keyframe.
  • Hits is sent when a video stream receiver is experiencing a gap in the packet sequence and has paused decoding to avoid the introduction of video artifacts into the image. H is imperative that the command is serviced as soon as possible to get smooth video playback.
  • Data block transfers are used by Z-Platform's A/V Communication host applications to transfer media data other than real-time audio and/or video.
  • An example is a shared image or document, which the application distributes to session participants around which a conversation takes place.
  • the platform's Communication Service doesn't require knowledge of the type of data contained in the block rather it is viewed as an opaque binary block of data of some arbitrary, but specified size.
  • the primary requirement is to transfer the data efficiently without disturbing the audio/video portion of communication, rather than low latency.
  • the data block may be large (several megabytes in size) and thus split into many packets. There is no requirement to maintain the order of individual packets that make up the data block.
  • Data block transfers are categorized into 3 priority channels, plus a 4th unreliable channel, which is also described below.
  • the three reliable channels allow data transfers to be separated by low, medium, and high priority.
  • An example use would be to send a large image over the low priority channel while smaller chat messages arc sent on the high priority channel, in this example, the chat message is likely delivered before the image even if it is sent afterward (but before the image transfer has completed). Within a channel transfers are guaranteed to be delivered in the order they are sent.
  • a data receiver delivers the data block to the application layer immediately upon receipt of the final fragment (and after assembling fragments into a contiguous block) assuming ail previous transfers on that channel have also been delivered. If not, Z-Platform's Communication Service holds the block until previous blocks have been completed so they can be delivered in the order they were sent.
  • CommNodes receive ACKs from all data-receiving participants in the session and track packet reception. After each round of ACKs is received the CommNode will combine this information into a single ACK command, which is relayed to the data sender. Thus from the sender's point of view, there is just one receiver. CommNodes can use packet reception info to filter resends to only recipients that need them.
  • the 4th unreliable channel allows for transfers of small (currently limited to I k byte) pieces of low latency data that doesn't require reliability (i.e., they arc not recovered if packet loss occurs).
  • This channel is intended for application defined control messages thai, for example, provide for interactive control of a shared communication session resource, such as panning and zooming a shared image. Data transfers on this channel arc given higher priority than reliable data transfers due to their low-latency requirement, but lower priority than audio or video. Although reliability is not guaranteed on this channel, the data is still delivered to the application layer in the order it was sent.
  • the Opus audio codec used by Z-Platform s A/V Communication Services provides forward error correction (FEC), which can repair small gaps in the audio stream by recovering the previous packet, which is encoded in the following packet. Because a small playout delay is required at receivers to account for jitter and out-of-order packets, the next packet in the sequence following a single missing packet is usually available without further delay. However at the same time, to reduce latency, a relatively small frame size (currently I /50th of a second) is used so FEC is only able to cover a small gap.
  • FEC forward error correction
  • Z-Platform's A/V Communication Services use a custom RUDP protocol to recover packets and avoid gaps too large for TEC to handle. There is a requirement to maintain low latency if possible, but also avoid audible gaps. Audio RUDP attempts to balance these two goals.
  • the send queue buffers audio packets for resend up to a limit (currently approximately 30 seconds of audio). Strictly speaking this protocol does not guarantee 100% delivery of all packets. If audio data becomes too old, it is no longer relevant to an interactive conversation and is dropped, unfortunately producing a gap in the stream. However audio stream receivers will pause playback if necessary up to a certain threshold in an attempt to recover missing packets. Once the stream resumes, playout will skip silent frames to return to acceptable latency. Note that some silent frames are left in place so as not to alter the structure of speech.
  • audio data is a continuous stream with packets arriving at a fixed rate (50 FPS). Therefore ACKs arc also sent at a fixed rate (also 50 FPS). They primarily consist of the greatest received sequence number (GRSN), which is a single unsigned 32-bit integer value, and a list of out-of-order received packets (represented by their 32- bit sequence number).
  • GRSN greatest received sequence number
  • ACKs also include a late time, measured in session clock ticks, which is the amount of time the
  • GRSN + 1 packet is considered late compared to a threshold.
  • This threshold is the minimum rime-to-live where packets are expected to be received and ready to be decoded so audio sample data can be presented. Note that the late time may be negative, which is often the case when packets arrive in a timely manner, in this case the late time is clamped to zero so it can be stored as an unsigned timcsiamp.
  • GRSN-M packet is not late.
  • the audio sender will continue to store packets for resend, but discard them when the threshold limit has expired even if they have not been ACK'd.
  • CommNodes track audio packet reception for each receiver and combine this information into a single ACK stream sent to the audio publisher. From the point of view of the publisher, there is just one receiver and one incoming ACK stream. However in this case all receivers must ACK even if their GRSN is not late in order to keep packet reception info at the comm node up-to- date and produce correct combined ACKs from the Communication Node.
  • an audio publisher When an audio publisher receives an ACK, it resends packets that arc late and have not been received. If the packet indicated by the ACK command with sequence number equal to GRSN + 1 is late it is the first to be resent. Subsequent packets (GRSN+2, ⁇ 3, ...) can also be resent if they are also late and not received as indicated by their lack of presence in the ACK command's out-of-order received packet list. A subsequent packet's laic time is easily calculated by subtracting the audio frame duration from the late time of the GRSN +n packet. After some number of subsequent packets that late time is less than zero and no rosend is needed. Audio frames arc typically small (a few dozen bytes) so a single packet is able to transport multiple resend pockets.
  • Z-Loeker and Z-Shelf services (collectively known as Z-Store services) arc Z-Piatform Modules providing personal cloud storage services with enhanced security.
  • Z-Locker was originally modeled after the luggage lockers at public spaces (such as (rain stations), utilizing the same lock approach tor depositing and retrieving contents. Its usage was deliberately kept simple; find empty locker (use system- provided functions to automate), deposit content (utilizing Z-Platform secure channels), lock door (activate access control), remove key (change to read only), give key to recipient.
  • Enhanced features include key-expirations (both time and number of usage), content disposal (both time- and access pattern- based), "multiple-retrieval " ' option (such as in newspaper vending machines).
  • Z-Shelf differs in its access mechanism; it is effectively a public Z-Lockcr with simplified controls, while retaining the time and basic allocation and retrieval functions, it is mostly used as Z-Platform's enhanced security CDN solution.
  • Z-l..ocker utilizes Z-Shelf in the background to store Z-Locker contents.
  • PBKDF2 Location Reference Name
  • CEP Content Encryption Passphrasc
  • the computed ZLjLOCATTON:ZLLTOKEN is already occupied, a new PIN is generated and a new ZL LOCAT10N:ZLLTOKEN pair is calculated. If all attempts fail, the ZP-PM responds with a failure and a new LRN is requested, which can either be a request for a user to change the location reference name, or a new random ID is generated. If the computed ZL_LOCAT10N succeeds, the ZL_LOCAT10N locker gets allocated in the Z-Locker infrastructure and the associated SHA3_512(ZLLTOKEN) is stored in it. The generated PIN is transmitted back (symmetrically encrypted with SI IA3_512 ⁇ LRN)) to the client application and is shared with the user.
  • the client has in its possession LRN, CEP and PIN (symmetrically decrypted with SHA3 512(LRN)). Based on the above formulas (which were executed on the server), the client generates ZL_LOCATION and ZLLTOKEN. The client can now proceed to encrypt the content which is then transferred for storage in the Z-Locker facilities.
  • the client generates a 62 byte SALTZLCKP. 2 byte ITERATIONZLCKP, 32 byte IVZLK (4 salt ⁇ ⁇ ⁇ 28 IV), 64 byte
  • ZLK_CHALLENGE and a 64 byte ZLPEK (Package Encryption Key Seed). T he client then proceeds to compute the Package Symmetric Encryption Key (ZL_KEY):
  • LCDR Locker Content Deposit Request
  • This LCDR is sent to the Z-Locker infrastructure with the locally computed
  • the receiving platform module server checks if the
  • ZL LOCATION is allocated by the user'persona and if the ZLLTOKEN is the same in the referenced ZLJLOCATION. If both of these tests pass, the Data Storage is allocated (with Z-Shclf), a Z-Locker System Symmetric Key (ZLSSK) is generated, the content gets encrypted with it and CRC hashed (ZLSSKCRCH ). gets deposited in the allocated Z-Shelf location, and the ZLSSK and Z-Shelf location is added to the LCDR content for the associated ZL LOCATION.
  • ZLSSK Z-Locker System Symmetric Key
  • LCRAR Locker Content Retrieval Authorization Request
  • the server sends down 1 VZLK, HMAC(IVZLK).
  • the server registers the retrieval event, updates its records and watts for a "content downloaded" event. Once proper download of ihe content is verified (checksum and length verification), the records are updated and modified for the associated Z-Locker (content may be deleted upon "bum” lockers).
  • the client Once the client is in possession of the payload, it sends a "content downloaded" event to the Z- Locker service which in return (after verifications) sends back the ZLSSK. and ZLSSKCRCH encrypted with the User's Public Key. With the decrypted ZLSSK/ZLSSK.CRCH, the client performs an integrity check and decrypts the payload, effectively removing the system imposed outer encryption layer.
  • IVZLK computes its own HMAC(IVZLK) and compares it with the received one
  • the AES_GCM decryption it verifies if the received and computed AuthTag values match. If they do, a successful content retrieval was achieved.
  • Z-PlatfornVs Application Gateway Services provide access for registered third-party applications to Z-Platform services. Application registrations, permission assignments, certifications and other account management-related tasks are handled by the Application Management Services Module. Through this service are the requests made by the ZP-App developers and approvals granted or revoked by Z-Platform's ZP-App Account Managers.
  • the Platform Management Service module provides access to Z-Platform maintenance services for managing device registrations and associations, user and persona certifications, changing die
  • the main purpose of the Payment Connector Service Module is to provide functional ity for turning internal accounting information into real world financial transactions.
  • user verification is part of this process in order to fulfill a fundamental Z-Platform requirement of non-anonymity.
  • Exemplary embodiments include establishing local e-valets that track income/spending and are synchronized with accounting information (where free items are also tracked). Valet transactions affect real money utilizing a Hosted Card Capture approach with Payment Tokcnization. where MINE Zero Inc. is a registered Services Account Holder in possession of a unique Merchant ID and the associated Security Elements. This reduces the burden of PCI DSS (Payment Card Industry Data Security Standard) and enables the platform to switch to new and emerging payment methods as required.
  • PCI DSS Payment Card Industry Data Security Standard
  • new transactions can be performed on credit or debit cards which were used during the user registration process by passing information to the Payment Gateway Services on previous transactions, such as during registration and consequent transactions.
  • Z -Platform uses the registration transaction (nominal fee charged or credited) as the root of the linked trust process.
  • the process tracks payment provider dependencies (such as timing- related limits between transactions, card expirations) and stores only what is truly needed to maintain an active payment status, such as the value, type, and reference identifications to the previous transactions. Individual payments then can follow the usual Payment Authentication Request/Response path with the Access Control Servers and Payment Gateways for executing financial transactions.
  • the main purpose of the Know-Your-Customer (KYC) Connector Service Module is to establish and verify real world entities (real persons) utilizing known third-party KYC services.
  • KYC Know-Your-Customer
  • An Authorization Code Grant process is initiated on the client app.
  • a separate screen is invoked on the user's device (in order to avoid violation of trust boundaries) to establish the KYC link.
  • the third party's authorization service checks whether the customer is valid utilizing their own login mechanism (usually through an account identifier such as an FKN or user name - and PIN combination) and the authorization code will be handed over to the 2- Platform response handler.
  • the app also informs the platform about the invoked process and hands over the same unique identification (also known as state parameter to avoid CSRF attacks) as it was handed over to the third party's authorization service.
  • Z-Platform then verifies the return state and exchanges the received code to an access token.
  • This access token ⁇ bearer access token
  • Z-Platform may provide message delivery for
  • HMDS ZP-Applications by utilizing the Platform Mail Delivery Serv ice Module for setting up message deliveries while utilizing the earlier discussed Unified Message Delivery System for handling the actual delivery process of messages.
  • messages are created with envelope information containing addressee (ZP-App-lD and ZP-App-Persona-lD) and may contain delivery requirements (delivery time, delivery charges).
  • HMDS only acts as a delivery service, while the PMDS Module is responsible for proper target setups (addressee) and delivery requirement definitions, verifications and executions (paid messages need to be registered with the accounting services).
  • Z-Platforro's Server-side services On top of providing the Z-Platforro's Server-side services and detailed descriptions of ottered services, client sample codes for utilizing the platform services for tOS and Android are also provided. All security transforms and core processes are implemented in C and are also available as libraries. Transactive communications are executed utilizing Protocol Buffers taking advantage of its robust serialization and deserialization features. Detailed description on its usage and organization is provided elsewhere herein.
  • the Z-Platform Client SDK contains all necessary APIs to initiate platform requests and handle platform responses while providing the necessary security functionality. Addressing Secure Data Retention Compliance
  • Z-Platform Since Z-Platform is inherently secure, Z-Platform operators do not have the ability to decipher exchanged messages between platform users. While this feature is at the platform's core and is an uncompromisable offering, certain scenarios may require the ability for authorized operators (such as in the Enterprise Edition) to be able to decipher and record exchanged messages between predefined users in order to comply with government mandated retention policies. As the platform servers have no ability to decipher the messages, enabling this feature requires client application modifications.
  • the developed application (ZPApp) is registered with a "Data Retention Required" flag with the Z-Platform's Application Gateway Service and during use, a dedicated channel is opened to a predefined data collection Z-Platform entity; the Data Retention Entity (DREj. This does not affect normal behavior of the base application; it only increases the outgoing bandwidth by a small factor. When users log in from their devices.
  • Z-Platform recognizes mat the connecting application is marked as "Data Retention Required * ' (DRR) and fetches data collection rules for the given user It also marks that connection has been established and registers the activity and its timcstamp with Z-Platform's Bi infrastructure This is an important feature which gets later cross-checked with the DRE logs. As the application running on the device has the DRR marker encoded in it, it will establish an immediate connection with the dedicated DRE on Z-Platform.
  • This DRE can cither be a universal recording entity (same DRE 'user' for all connecting platform users) or can be independently assigned to each user (DRE IDs have a hashed ZP AppID and ZPUserfD combinations included).
  • the DRE entity running on the platform marks the connection event in both its own Bi data collection facilities and in the user ' s Bf utilizing the platform ' s Core BI Serv ices. This marks in the Z-Platform's BI records that a successful DRE connection was established. Subsequent recorded events (such as conversations with other users required by company policies) arc then collected on the client, compressed and secure packaged the same way as normal user-to-user communications do. Effectively, the overhead is very low, the messages are just sent to 2 users; one being the original target the second one the DRE.
  • hashes of the original texts are also sent, which get registered with Z-Platfbnn's BI in case of DRR flagged activities.
  • This feature enables a deeper level of cross-referencing message integrity between DRE services and Z- Platform ' s standard ⁇
  • the DRE receives a copy of the transmitted mcssagc(s), it decrypts it then computes the hash and may cither immediately cross-reference its own hash with the original Z-Platform ⁇ hash (immediate integrity check for real-time verifications) or simply store it for later integrity checks.
  • Z-Platform DREs can cither store the re-encrypted data logs with Z-Platforra, or ⁇ preferably - utilize their own compliant, external data collection and storage services. Connection between Z-Platform DREs and their data collection services can be established and maintained by industry standard approaches, such as dedicated VPN 1 incs or other form of end-point protection facilities. If data access is required at a later date, the DRE's data store has all the necessary information which can be verified against Z-Platforra's BI for integrity via the message hashes and timestamps, unless real-time verification took place.
  • Part 3 The purpose of Part 3 is to provide a design overview and describe the architectural
  • Part 3 is organized into the follow sections:
  • Unified Message Delivery System (UMDS)
  • AGS Application Gateway Services
  • AMS Application Management Services
  • FIG. 18 is a diagram of a Z-Platform Services Component Model 280.
  • the underlying support structures for these platform features can be generally divided into three basic access patterns:
  • Z-Platform Public API represents a unified destination for accessing Z-Platform features across the range of core services, platform modules, and internally hosted Z-Platform apps. These API offerings are generally consumed by Z-Platform client libraries 286 and externally-hosted Z- Platform apps 287. Technologies / Methodologies
  • Z-Plaiform's development methods emphasize quick prototyping and development agility, while keeping an experienced eye toward future scaling and potential regulatory compliance needs.
  • the stack choices reflect the collective background launching, monitoring, scaling and optimizing high- concurrency production web services, data persistence and mobile properties
  • Dynamic language-based web frameworks field boilerplate HTTP request/response handling, business logic, object-relational mapping, offline queuing, etc.
  • Z- Platform's software development choices favor industry-standard open-source components which leave the platform's intellectual property acceptably unencumbered from a licensing standpoint, and also have widely-traversed commercial / managed-service analogues. Development tools and frameworks arc chosen to enable the growth of the platform team efficiently, to allow for interoperability with a breadth of open-source standards, and scale efficiently to meet the needs of the production environment. Platform design plans also include utilizing professional solutions for mission critical systems both for final-stage developments and deployments. As the local and/or international regulatory compliance is becoming an imperative for the supported business model, the majority of the deployed practices, controls and tech stack components are ready to meet OWASP, ISO27001 , SSAE16 and ISAFJ402.
  • Pfatform's basic infrastructure is built from common components that standardize the utilized approaches to the task of splitting popular API features out into individually-scalable services and growing the data sets as demand/traction increases.
  • FIG. 19 is a diagram of a Z-Platform Public API Proxy / Load Balancing scheme 290 according to an aspect of the invention.
  • Z-Platform For software load balancing, Z-Platform utilizes the well-established HAProxy suite, which comes in an Enterprise Edition and in optional ALOHA Load Balancing Appliances.
  • a high-availability configuration enables routing decisions to be made based on the content of an ⁇ request and then proxy requests to multiple backend services as necessary.
  • HAProxy fronts the API from edge servers back to individually scaled services behind the scenes.
  • Linux cluster/heartbeat daemons between primary and secondary HAProxy boxes 292 and 293, they arc configured with a shared (floating) IP to accommodate in case of a failover.
  • DNS round-robin implementation (with health- checking) enables the scaling of the HAProxy configuration horizontally.
  • Z-Platform has the ability to change from its current basic round-robin load balancing strategy.
  • FIG. 20 is a diagram of a Z-Platform Service Front Layer Stack 300 according to an aspect of the invention.
  • proxied requests are load-balanced by HAProxy across several Front Layer servers 302 (which may be added or removed as necessary).
  • Each Front Layer 302 server uses NGINX locally to receive and pass HTTP requests (slow client connections) to the web application via a shared Unix socket (fast client connection).
  • Each web application generally has one or mote databases for similar persistence layer) to which it must connect, and is provisioned with SSL certificates to do so over encrypted channels.
  • the Front Layer stack includes a master process that monitors and maintains a pool of workers running the service's web application code (Unicom).
  • Each server is configured, initialized, deployed, and continuously monitored by ⁇ -Platform's configuration management and automation framework (CFEngine) through an agent process (or Release Management Daemon) which periodically reports the compliance state of each system. Similarly, each server maintains an agent process for reporting its resource utilization statistics (CPU, Disk, Network, etc.) to the platform's distributed monitoring system (Ganglia).
  • CFEngine configuration management and automation framework
  • agent process or Release Management Daemon
  • the front layer server also provides a local buffering and delivery process tor handling application log and business intelligence data (Fluentd).
  • This service is a non-blocking one-way pipe that collects, parses, transforms, and securely delivers various types of data to the platform's analysis tools and/or data warehouses. Whenever applicable. Flucntd supports retry, failover, and local buffering to provide guaranteed deli very of logged data.
  • NGINX pronounced Engine-X
  • NGINX receives requests, validates SSL certs, terminates SSL/TLS, interprets, buffers, and forwards requests in a time- domain-adjusted fashion to the platform API services. NGINX benefits from zero-downtime
  • NGINX - Provides another line of defense against DDoS attacks with configurable options for request rate limiting, limiting the number of concurrent connections that can be opened by a single client IP address, timing out slow connections, and IP blacklisting'' whitelisting. It also shields upstream platform services by allowing configurable per-scrviee connection limits while proxying requests (in the case of the Public API).
  • Web Application Firewall - WAF is deployed to protect the platform's web applications (or a set of web applications) in conjunction with rules for the known-acceptable access patterns
  • implementing WAF rules per service are straightforward.
  • Naxsi NGINX Ami XSS &. SQL Injection
  • OWASP Open Web Application Security Project
  • Offline worker pools may also employ native extensions to compiled system libraries, JVM- based classes, NodeJS and other platforms thanks to a wide availability of client ports for Sidekiq.
  • Bl / Logging Collector - Z-Platform maintains a unified data logging and analysis pipeline that begins with a Fluentd collection agent on each front layer server.
  • the application may push logs and sanitized business intelligence (Bl) data to the Fluentd agent.
  • Fluentd is similar to other logging options like Sysiogd or Apache Flume, but offers many advantages over the majority of other logging libraries.
  • Z-Platfbrm uses it as a non-blocking one-way pipe that collects, parses, transforms, and securely delivers logged data. It does not lose data when a network failure occurs and afters retries, failover, and encryption of message channels.
  • the data is transferred to a central Fluentd agent that collects and distributes logged data to the platform data rerxisitories (Elasticsearch for real-time analysis and Hadoop's HDFS for data
  • the process provides non-blocking unidirectional delivery of logged data with built in fault tolerance.
  • Application code may publish data into the Bl pipeline for delivery to the data warehouses and/or real-time indexing system for analysis.
  • This model is meant to simplify security and enforcement of Z-Platform's data retention policies;, while simultaneously being fault-tolerant and non-blocking to the application code.
  • the data warehouse, analytics cluster and dashboards may all be physically segregated from Z-Plarform servers and data persistence resources for a greater degree of security.
  • Kibana an open-source analysis and dashboarding interface
  • Elasticsearch a Java-based open-source full-text search engine
  • Java-based open-source full-text search engine allow Platform product and technical staff to easily search, graph, inspect, visualize and analyze the data collected from the Bl pipeline to follow trends, measure performance or detect and inspect incidents.
  • Kibana Dashboard configuration is done entirely in the Kibana UL without code. Once the metrics data is delivered to the Bl pipeline, Kibana is used to create rich visualizations that update on the fly.
  • Resource Monitoring Agent - Ganglia an open-source distributed cluster monitor logs system performance and uptime across the deployed server ecosystem. Result sets can be easily customized (though the defaults arc usually sufficient for most resource monitoring needs) and arc automatically centrally dashboarded.
  • Deployment system run on Go Agents within the build and deployment ecosystem. Once tested, built and deployed, the continued compliance of all production systems is monitored and enforced by CFEngine (Z-Plaf form's configuration management tool).
  • Linux ⁇ .. Z-Platform's production distribution of choice is CentOS, the open-source version of Red Hat Enterprise Linux (RHEL).
  • Production DNS ⁇ In view of the platform's potential need for advanced DNS features like Geography-aware DNS, load-balancing and latency-based routing, Amazon Route 53 is currently targeted as the production DNS solution.
  • CDN - A combination of Amazon S3 API proxying (for high-availability bulk storage) and Amazon Cloudfront (for low-volatility static assets) has been specified as Z-Platfomf s current choice for CDN.
  • SQL-agnostic Data Modeling In an effort to keep the platform production environment portable between relational database choices, object-relational model usage was selected. This provides a rich language for data modeling while keeping Z-Platform technology agnostic.
  • the application code is largely decoupled from any specific SQL-variant and leverages adapters that are used for a variety of persistence layers.
  • FIG. 21 is a code snippet 310 that illustrates how the platform table schemas are written in code and are portable to any SQL choice. Table attributes and indices for a wide variety of relational databases are described in this SQL-agnostic modeling layer.
  • FIG. 22 is a code snippet 320 that provides a sample of how the relationships between platform data models are defined.
  • Z-Plaiform development defines data models and migration files which translate to many relational databases.
  • the platform's data modeling layer compiles SQL queries from simple, expressive set of Class and instance method that match specific requirements from the relational databases (for example: "Session.wheret status: 1N_PR0GRESS)" instead of "SELECT * FROM sessions where status « 'INJPROGRESS V).
  • FIG. 23 is a code snippet 330 that demonstrates how calling the ZUser class methods build the SQL queries for the current SQL implementation.
  • Cross-platform Messaging and Object Serialization / Deserialization - Google Protocol Buffers are a language-neutral, platform-neutral, extensible mechanism for serializing structured data Z-Platform uses them extensively for creating and implementing cross-platform object
  • Protobufs allow the platform to define the data to be exchanged between a client and server in a single, canonical location (the .proto file). T hat definition is then compiled into the server- and client-side libraries (Ruby, Objective-C C++, Java), which automatically generates all the boilerplate code tor handling common message tasks like serialization and deserialization, attribute getters and setters, object validators and introspection methods.
  • server- and client-side libraries (Ruby, Objective-C C++, Java), which automatically generates all the boilerplate code tor handling common message tasks like serialization and deserialization, attribute getters and setters, object validators and introspection methods.
  • Protobufs also provide backward compatibility support for mobile clients thai may lag behind the latest release cycle and the wire size for Protobufs are often much smaller than competing serialization formats (like JSON).
  • FIG. 24 is a screenshot of a Java listing 340, demonstrating how Java Protobuf classes are added to Android projects.
  • Protocol buffers currently support generated code in Java, Python, and 0-* ⁇ With the latest proto3 language version, it also works with Go, JavaNano, Ruby, and CM. Z-Platform ⁇ s choice of the Protocol Buffers is rooted in emphasizing simplicity and performance. In particular, it was designed to be a smaller and faster interchange format than XML and is not encumbered by RPC references.
  • Protocol Buffers are similar to the Apache T hrift (used by Facebook) or the Microsoft Bond protocols.
  • FIG. 25 shows a .proto file listing 350 that is an excerpt from
  • FIG. 26 is a code snippet 360 auto-generated by Ruby that is available to the server project.
  • the Z-Platform provided Core Services offer a variety access functions to user, device, and endpoint management, which will next be discussed.
  • the Device Registration Core Service specifically bootstraps the security relationship for all client devices. Initial provisioning of client devices is the first step every platform user takes on the way to enjoying subsequent platform services. Design / Service Goals
  • the Device Registration Service provides the required registration of user devices.
  • Z- Platform does not depend on manufacturer / device operating platform provided identifications for several reasons. This service filters all hardware entities that will access platform services and provides an API for registering and kick-starting the necessary cryptographic services and account credentials (largely automated by client-side libraries).
  • Z-Platform clients compute their own device IDs, which arc essentially 32-byie unique identifiers generated from entropy sources and their digests. Upon successful registration a signed device certificate is generated, stored, and communicated back to the device for consequent communications.
  • Device registration is a necessary step in joining the Z-Platform infrastructure, as clients are required to satisfy the platform's 2-way mutual TLS authentication requirements using client-side X.S09 authentications.
  • client-side X.S09 authentications Upon a client establishing a TLS connection, the presented client certificate is checked for validity (verifying if it was signed by Z-Platform " s Client SubCA ⁇ ⁇ ⁇ discussed in greater detail elsewhere herein) and if the certificate has been black-listed or not.
  • the black-list is maintained by automated scripting which updates the list file and refreshes the TLS terminator ' s associated links.
  • FIG. 27 is a diagram of an exemplary technology stack 370 for a Z-Platform Device Registration Services module according to an aspect of the invention.
  • this service features disk-based row stores to store the Device IDs and their associated registration / usage information. The data is used when a user logs in to verily device-user associations and established standard usage patterns.
  • the two storage components are:
  • an atomic in- meinory cache (utilizing Rcdis, according to the platform's current implementation initiative) facilitates centralized state management for all front-layer API servers.
  • User and Persona accounts are at the core of Z-Platform * s value offering.
  • User accounts have real people with real identities directly associated with them, while persona accounts are different representations of and are rooted in the user accounts.
  • Personas are customized user representations with the purpose of identity protection and ZP-App domain-specific expansions.
  • identity protection and ZP-App domain-specific expansions In order to minimize possible information leakage between the different application domains, and to provide maximum resilience against both logical and physical attacks, all stored information is segregated into several chunks with different security domains and rules. Persona information is stored independently (both logically and physically) from the User Accounts and there is no direct link going from Personas to the User. The association and logical linking is done by using Z-Platform's Identity Translation Services (I TS) for which identity seeds are also stored separately.
  • I TS Z-Platform's Identity Translation Services
  • VEP - stores Persona preferences
  • RWPI ⁇ stores links to the physical world, such as payment and know-your-eusiomer references
  • FIG. 28 is a diagram of an exemplar)' technology stack 380 for a Z-Plaiform User and Persona Management Services module according to an aspect of the invention.
  • the implementation of the user and persona account / management services arc similar to other basic web services behind a load balancer 381.
  • Establishing valid sessions start with the AIM process (utilizing REP and SEC) and consequent user / persona data manipulation takes advantage of the AIM session validation module.
  • An exemplary implementation utilizes 6 distinct row-based data stores:
  • RWPI Real World Personal Information
  • VEP Virtual Entity Preferences
  • References are implemented from one database to another, but no single source connects real world personal information to user accounts or personas or their various platform preferences.
  • ITS Identity Translation Service
  • Z-Platform guarantees the protection of PU (Personally Identifiable
  • ZP-Apps Z-Platform applications, platform-based independent systems running inside the Z-Platform Ecosystem
  • Z-Platform users Z-Platform users via ⁇ - ⁇ domain specific IDs once proper access has been granted. The IDs are then used to contact other users, and they are stored in the ZP-App specific contact lists. These IDs however do not directly refer to the original Z-Platform users, nor can they be found in the Z-Platform stored databases. This level of abstraction protects against matching ZP-App IDs to Z- Platform users (teal people) in case a ZP-App (or even if the Z-Platform) databases are compromised. There is no information leakage between the ZP-App and the Z-Platform user identifications, nor between different ZP-App domains. Detailed description on the used process and algorithms can be found in the TDD.
  • FIG. 29 is a diagram of an exemplary technology stack 390 for a Z-Platform Identity Translation Services module according to an aspect of the invention.
  • the front layer 391 accepts requests from strictly internal Z-Platfbrm entities 392, so it verifies sources before working on identity translation requests. As new identities are created for a given user-app context, they are stored in the Identity Record Storage database 393. For subsequent translation requests, the mechanism for finding a given translated identity is a combination of database lookups and mathematical formulas.
  • Unified Message Delivery System (UMDS)
  • Z-Platfbrm's UMDS is a centralized and precision tuned mailbox system that facilitates message exchanges between users / personas / applications. In combination with the Platform Mail Delivery Service (PMDS), it provides the backbone for the platform's postal services as well.
  • PMDS Platform Mail Delivery Service
  • the approach was modeled after the standard postal services utilizing PO Boxes. Different from email systems, the actual messages are not stored within user/persona mailboxes attached to the user/persona information, but in a PO Box. allocated from Z-Platfbrm's UMDS services. The allocated ("rented") PO Box ID is stored with the User/Per&ona Information during User/Persona creation time.
  • PO Boxes store small-footprint messages directly, larger ones follow the "parcel notification ' ' approach; the delivered message is tagged with the delivery information (ZP-App-ID and Per-App- Persona-ID, Delivery Parameters) while the actual payload message gets encrypted with a symmetric key, has a unique ID assigned and is stored within the UMDS storage facilities, utilizing the platform's Z-Shclf solution.
  • the key and the unique ID arc added to the Delivery Parameters with a X509 v.3 encapsulation (using the public key of the addressee) guaranteeing total privacy and protection of both message and delivery notifications independently.
  • Unified Message Delivery System represents a sizable challenge for scaling voluminous data associated with not only message creation, delivery, and reporting; but also the secure storage of cryptographic elements related to these messages in transit.
  • FIG. 30 is a diagram of an exemplary technology stack for a Z-Platform Unified Message Delivery System (UMDS) module 400 according to an aspect of the invention.
  • UMDS Unified Message Delivery System
  • the technology stack behind this platform service looks similar to others with its load-balanced front layer resources 401.
  • Each validates session information through the AlM's Session and Access Matrix module prior to any interaction with the UMDS API.
  • PMDS Platform Mail Delivery Service
  • delivery requests are set up and stored assuring that appropriate rate limiting, send permissions, service restrictions, bans and recipient preferences are observed.
  • PMDS Platform Mail Delivery Service
  • the above diagram only describes the message delivery system and does not go into detail of the postal services.
  • the main difference between UMDS and PMDS lies with the access controls. If the sender and the addressee has direct access links (they are in each other's contact list, or they are currently in a real-time
  • UMDS can be utilized.
  • This service integrates with the underlying Z-Shelf secure storage service 402 and therefore requires persistent storage resources 403 for handling its own record-keeping. Encrypted message content is pushed off to the secure storage infrastructure (as with Z-Shelf and Z-Loeker).
  • AOS Application Gateway Services
  • AMS Application Management Services
  • the Application Management Services Module handles ZP-App registrations, permission assignments, certifications and other account management related tasks.
  • the Application Gateway Services enforce the established rules by providing access request handlings and reservation services for the given outside-hosted ZP-App towards platform resources. Design / Service Goals
  • the Application Management Service Module's API encompasses
  • the Application Gateway Services provides API services to registered ZP-Apps:
  • the design requires resources and systems for handling static marketing-related content (graphics and potentially video); post-processing, optimization, and CDN-likc caching/replication of static content.
  • ZP-App marketplace presentation will typically involve full-text search services and subsequent semi-real-time indexing resources.
  • Z-Platform Account Managers use this same API to review and approve/reject ZP-App related submissions, change requests, etc.
  • FIG. 31 is a diagram of an exemplary technology stack 410 for a Z-Locker Application Gateway Services (AGS) Module according to an aspect of the invention.
  • AGS Application Gateway Services
  • the Application Gateway Service shares much with the architecture of the Device Registration Service.
  • the service confirms the ZP-APP's access through the ZP-APP Registry database 411. Once this has been validated, a reservation (much like a validated session) is added to the Reservations Cache 412 with an expiration time (TTL). The reservations will be confirmed by an AGS module when the ZP-APP continues to their reserved platform services.
  • FIG. 32 is a diagram of an exemplary technology stack for a Z-Locker Application Management
  • AMS AMS
  • ZP-APP Registry 421 is shared between the AGS and ZP-App Management Service Module (AMS) to guarantee the setup and the access control enforcements.
  • the Application Management Service Module API handles indexing of searchable records within the ZP-APP registry Elasticscarch (a Java-based open-source full-text search engine) is utilized for providing a wide array of search features. It is also important to note that the Application
  • Management Service Module facilitates of both upload and post-processing tasks of static assets (perhaps pictures or video). These assets are added to a queue for offline processing by a pool of workers responsible for preparing media for the ZP-APP marketplace. While this may result in a slightly delayed update to both static assets and their presence in the ZP-APP Registry once uploaded, it provides better sealing and a more balanced resource management.
  • the Z-Locker and the Z-Shclf service is a Z-Plaiform Module providing a personal cloud storage service with enhanced security for Z-Platforra's users and their persona*.
  • Z-Locker was originally- modeled after the luggage lockers at public spaces (such as train stations), utilizing the same lock approach for depositing and retrieving contents. Us usage was deliberately kept simple; find empty locker, deposit content, lock door, remove key, give key to recipient. Enhanced features include key- expirations (both time and number of usage ), content disposal (both time and access pattern based), "multiple-retrieval" option (such as in newspaper vending machines).
  • Z-Shelf differs in its access mechanism: it can be described as a public Z-Locker with simplified controls, while retaining the time and basic allocation and rctrieval functions. It is mostly used as Z- Platform s enhanced security CON solution.
  • Z-Locker utilizes Z-Shclf in the background to store Z- Locker contents.
  • the Z-Locker Service Module is designed in a similar fashion to the UMDS service, as it largely benefits from the secure storage features the Z-Shelf Service
  • FIG. 33 is a diagram of an exemplary technology stack for a Z-Locker Service Module 430 according to a further aspect of the invention.
  • a significant processing element of this module is the content encryption work module, which encrypts the payload with a randomly generated symmetric key, adds the key (with CRC and pay load size) to the lacker Entries database 431 and pushes the content to the Z-Shelf data management service 432.
  • the content is sent to the client and the Z-Locker Serv ice Encryption Key is shared with the client upon successful authentication and retrieval in an X509 v3 fashion.
  • the Z-Shelf Service Module is designed to provide Z-Platform with a secure, advanced CDN- lype blob-store functionality. Shelf entries comprise of access rules and parameters and an internal reference to a bulk key/value content storage.
  • FIG. 34 is a diagram of an exemplary technology' stack tor a Z-Shelf Serv ice Module 440.
  • the Z-Shelf Service API is largely responsible for storage and retrieval of data it receives.
  • data is uploaded to Z-Shelf, its associated storage options (like content expiry time) and access parameters (who can access this data and how many times it may be retrieved) are added to the Shelf Entries database 441.
  • Entry records contain references to the associated content in the Z-Shelf bulk storage 442.
  • Amazon S3 is utilized to meet the backend storage needs of the Z-Shclf Service Module (as it did for Dropbox). but the design of implementing a custom solutions is also available.
  • the Z-Shelf Sen ice Module's application layer generally governs access rights and storage limits for Z-Platform entities (who can store data, who can retrieve data). Once users are authorized to store or receive a given amount of data, Z-Shclf provisions the appropriate space inside of its bulk storage platform (through the Amazon S3) and ferries the data to its storage location.
  • Audio/Visual Communication Service Module
  • Communication Service ('ore. the Communication Control Center, and the Communication Nodes.
  • the Communication Service Core provides a service API for Z-Platform personas and ZP- APPs to reserve Audio/Visual sessions between each other. This service provides accounting and reporting services for sessions, both free and paid. CommCore enforces persona access rules according to their stated preferences. CommCore reserves session resources with the Communication Control ('enter.
  • the Communication Control Center's (CommCtrl) role is that of a service provider for A/V sessions (and is specifically concerned with handling service requests from CommCore).
  • CommCtrl maintains the available pool of Communication Nodes (CommNodcs), which may reside across many geographically distinct locations. It also monitors CommNode performance, latency, workload in order to choose the most appropriate CommNode(s) to service a given A/V session.
  • CommCtrl is capable of sending notifications to CommCore as session events occur (participants join or leave, performance thresholds, etc). Conversely, CommCore may subscribe to session events to monitor and report on sessions that are in progress.
  • CommNodcs themselves act as endpoint providers for secure streaming A/V sessions. At times, single A/V sessions may benefit from being bridged across multiple CommNodcs.
  • FIG. 35 is a diagram of an exemplary technology stack for a Communication Service Core (CommCore) module 450.
  • Communication Service Core Communication Service Core
  • the Communication Service Core stores A/V Session-related information in a relational database 451 and accounts for session usage between personas. It relies heavily on the Identity Translation Service (ITS) to ensure the privacy of session participants. As a rule, participants are identified by a different ID in each part of the Communication architecture ⁇ CommCore, CommCtrl, and CommNodcs). After enforcing each personas contact/access preferences, CommCore contracts the necessary session from the CommCtrl API and notifies all participants involved of the session.
  • ITS Identity Translation Service
  • the Communication Serv ice Core also subscribes to event notifications from CommCtrl by providing an endpoint to CommCtrl during session initialization.
  • FIG. 36 is a diagram of an exemplary technology stack for a Communication Control Center (CommConirol) Service API module 460.
  • the architecture of the Communication Control Center is configured to provide a scalable service offering.
  • Its service API is provided by a front-layer 461 that specifically handles requests for A/V Session services and begins the process of converting them into contracts within the CommCtrl system.
  • the front-layer queues work that must involve sessions among available CommNodcs and the contracted work is tracked as it is handled by each worker within
  • the CommCtrl worker pool 462 is tasked with all work that requires interfacing directly with CommNodcs. After a service request has been handled by a worker, completed work is logged with its respective service contract, and an HTTP response is returned from the Service API.
  • FIG. 39 is a block diagram showing an exemplary embodiment of a communications and transactional platform according to the invention.
  • Communications Platform 3900 comprises a Server 3902, a Content Transformation Module 3904, and a Digital Content Resource 3906.
  • the Content Transformation Module 3904 can comprise an Identity Translation Service Module 3905.
  • the server 3902. which can be constructed in accordance with known server/digital processor principles. methods and structures, contains a digital processing resource 3907 composed of one or more digital processors 3908, and is operable to communicate with other entities, such as clients-'endpoints/users 3920, such as by utilizing conventional network architectures or means, such as the Web or Internet 3990, cloud-based architectures, or other known configurations.
  • the digital processors) 3908 (and the digital processing resource 3907 formed collectively by the processors 3908 and any ancillary structures associated with the processor ⁇ )) can be of conventional design and construction. It should also be noted that Communications Platform 3900 can also form part of or the entirety of, and can functionally create or help create, a Communications Platform Environment 3901 , as described elsewhere herein.
  • the Digital Content Resource 3906 can be constructed in accordance with known digital storage techniques, methods and structures, and is operable to store, deliver or forward digital content, for example, in response to requests 3950 for content 3940. Examples of structures suitable for the Digital Content Resource include, but arc not limited to, disk -based storage arrays and the like.
  • the requests 3950 for content 3940 can come from the serv er, either directly or. in accordance with exemplary embodiments of the invention, through the Content Transformation Module.
  • the Digital Content Resource can store deliver or forward digital content 3940 to the server directly, or, in accordance with exemplary embodiments of the invention, to the server through the Content Transformation Module.
  • the Content Transformation Module is operable to apply selected content transformations to digital content directed to (or towards) the server from the digital content resource.
  • requests from the server are shown as passing first through the Content Transformation Module before reaching the Digital Content Resource, it is also possible that the server may, in exemplary practices or embodiments, apply a given selected request directly to the Digital Content Resource.
  • the Content Transformation Module is shown as a module separate from the server and separate from the Digital Content Resource, it is also possible, in a given embodiment or practice of the invention, to incorporate the Content Transformation Module and its functions, as described herein, within one or more of the server and/or the digital content resource.
  • the functions of the Content Transformation Module could also be distributed in more than one of the server and Digital Content Resource structures shown in the drawing figure.
  • the Communications Platform 3900 comprises a Server 3902 comprising a digital processing resource 3907.
  • the digital processing resource comprising one or more digital processors) 3908; and a Content Transformation Module 3904, in communication with the Server and interposed between the Server and a Digital Content Resource 3906 operable to store, deliver or forward digital content, the content transformation module being operable to apply selected content transformations to digital content directed to the server from the digital content resource.
  • the Content Transformation Module 3904 is controllable by the Server via a communications channel 3912 to selectively request and establish endpoints and users 3920, and to enable selected encryption, on a per-endpoinf basis, of content specific to a given digital consumption endpoinf (the given digital consumption endpoint being among the established endpoints 3920), responsive to server-based information 3930 representative of endpoint status or endpoint-associated user status.
  • the content transformation module is operable to dynamically change encryption parameters for a given endpoint, responsive to the server-based information representative of cndpoint status or endpoint-assoeiated user status.
  • the content transformation module is operable to execute selected redirection of content 3940 or content requests 3950, on a pcr-endpoint basis, responsive to the server-based information representative of endpoint status or endpoint-assoeiated user status.
  • the content transformation module is operable to provide selected content transformation, encryption and delivery for applications programs ("apps") 3960 executing on the server.
  • the Content Transformation Module is operable to provide selected content transformation, encryption and delivery for Web-based services that execute on modules of the communications platform or server (e.g.. Web-communicating modules 3970) that are in communication with the Web.
  • the Web-communicating modules 3970 are depicted within the server, but alternatively, they can be outside the server, and providing the functions called for by the present invention.
  • Exemplary embodiments of the invention comprise a Communications Platform Environment 3901 supported by the server and the Content Transformation Module, the Communications Platform Environment being functionally organized into three levels (not shown in FIG. 39 but shown and described in greater detail elsewhere herein), comprising a Core Services i ⁇ vel, a Platform Modules Level, and a Platform Applications Level, wherein: ( 1 ) the core services level comprises core services usable by platform modules or platform applications: (2) the platform modules level comprises platforra- based functional modules operable to utilize selected ones of the core services provided by the core services level; and (3) the platform applications level comprises platform-based application programs operable to utilize selected ones of the platform core services or platform modules.
  • die Communications Platform is operable, as described in greater detail elsewhere herein, to enable a User of the platform to create and maintain a fictional identity (Persona) for use on selected venues served by the platform, wherein Persona information is stored independently from User information, so as to preclude unmasking of a User identity based on corresponding Persona information.
  • Persona fictional identity
  • the Communications Platform is operable, as described in greater detail elsewhere herein, to enable a given User to create separate, different, respective Personas for use with different, respective venues served by the platform.
  • platform-based logical links between a given User identity and a corresponding Persona are established, maintained and protected by a platform- based Identity Translation Service provided, in the exemplary embodiment of FIG. 39, by the Identify
  • the Identity Translation Service Module 3905 depicted in FIG. 39 within the Content Transformation Module. It should be noted that although for purposes of a given exemplary embodiment, the Identity Translation Service Module is shown as within the Content Transformation Module, the Identity Translation Serv ice Module and/or its functions may be, in other exemplary practices and embodiments of the invention separate from the Content Transformation Module Alternatively, in other exemplary practices or embodiments of the invention, the Identity Translation Service Module and/or its functions may be located in or executed by other structures in the platform configuration of the invention, including, by way of example, the server.
  • variotis other configurations and groupings of elements other than those shown by way of example in FIG. 39, arc possible and arc within the scope of the invention.
  • the Content Transformation Module and/or Digital Content Resource can be within the Server or selected elements of the Server.
  • platform structure depicted and described herein can be utilized for a variety of purposes, which can include providing secure private communications, and/or supporting secure, private transactions.
  • the present invention provides methods, systems, devices and computer program products that can be implemented as part of the computer software or computer hardware of a digital communications network, which may include digital processors, computers, "smartphoncs", tablet computers, or other computing devices, which may include mobile computing devices, that form part of a computer network or telecommunications network, along with memory, storage, and other conventional computer system or telecommunications system components. While conventional components of such kinds are well known to those skilled in the art, and thus need not be described in great detail herein, the following overview indicates how the present invention can be implemented in conjunction with such components.
  • aspects of the invention can be implemented in software, hardware, or a combination of software and hardware, using otherwise conventional network architectures and digital processing apparatus including devices such as servers, personal computers (PC), smartphones, tablet computers, or equivalent devices operating in accordance with (or emulating) a conventional operating system such as iOS, Microsoft Windows, Linux, Android, or other, either in a standalone configuration or across a network.
  • a conventional operating system such as iOS, Microsoft Windows, Linux, Android, or other, either in a standalone configuration or across a network.
  • the various processing aspects and means described herein may therefore be implemented in the software and/or hardware elements of a properly configured digital processing device or network of devices. Processing may be performed sequentially or in parallel, and may be implemented using special purpose or re-configurable hardware.
  • aspects of the invention can be embodied at least in part in commercially available servers, PC's, tablet computers, smartphones or other mobile computing platform that contains functional elements suitable for implementation of the invention.
  • a commercially available serv er for example, suitable for implementation of aspects of the invention can include, for example, one or more processor.
  • memory and mass storage devices such as disk storage elements, which perform processing and storage operations in connection with digital data provided thereto.
  • the terms "memory”, “storage” and “disk storage devices” and the like can encompass any computer readable medium, such as a computer hard disk, computer floppy disk, computer-readable flash drive, computer-readable RAM or ROM element or any other known means of encoding digital information.
  • applications programs can encompass any computer program product consisting of computer-readable programs instructions encoded and/or stored on a computer readable medium, whether that medium is fixed or removable, permanent or erasable, or otherwise
  • Applications and data can be stored on a disk, in RAM, ROM, on other removable or fixed storage, whether internal or external, and can be downloaded or uploaded, in accordance with practices and techniques well known in the art.
  • the present invention can take the form of software or a computer program product stored on a computer-readable medium, or it can be in the form of computer program code that can be uploaded or downloaded, or fixed in a ROM or other electronic structure, or it can take the form of a method or a system for carrying out such a method.
  • digital processors, processing modules, servers and other processing structures discussed herein can include one or more network ports connected to communication links or channels which allow communication with, and within, a network, in accordance with known digital network practice, wherein a given processor or module can transmit information, content, data or requests to, and receive information, content, data or requests from, other computer systems and other devices in the network, in a typical network organized according to, for example, a conventional client-server paradigm, certain computer systems in the network may be designated as servers, which store data and programs (generally, "information") for processing by the other, client computer systems.
  • a client computer system that needs access to information maintained by a particular server can request, enable or cause the server to download the information to it over the network.
  • a network may also include, for example, other resources which may be shared among die various computer systems connected in the network.
  • the communication links interconnecting the computer systems in the network may comprise any convenient information-carrying medium, including wires, optical fibers or other media for carrying signals among the computer systems.
  • Computer systems transfer information over the network by means of messages transferred over the communication links, with each message including information and an identifier identifying the device to receive the message.
  • Systems, devices or software products in accordance with the present invention can operate on any of a wide range of conventional computing devices, systems and architectures, whether standalone, networked, portable or fixed, including conventional PCs, laptop computers, handheld or mobile computers, smartphoncs, tablets, or across the Worldwide Web ("the Web"), Internet or other networks, which may in turn include servers and storage devices and systems.
  • aspects of the invention can be embodied at least in pan in a commercially available sraartphone. tablet computer or other mobile device that contains functional elements equivalent to those noted above.
  • software applications configured in accordance with the invention can operate within, e.g., a PC or server, or known forms of handheld computing devices, smartphones or tablet computers, in which program instructions can be read from ROM or CD ROM, magnetic disk or other storage and loaded into RAM for execution by a processor such as a CPU.
  • Program instructions can be read from ROM or CD ROM, magnetic disk or other storage and loaded into RAM for execution by a processor such as a CPU.
  • Data can be input into the system via any known device or means, including a conventional keyboard, mouse, scanner, digitizing tablet, or other elements.
  • Applications and/or data can be located on some or all of fixed or removable storage or ROM, or downloaded.
  • FIG. 40 is a diagram of one form (although not the only form) of cloud configuration 4000 in connection with which the invention can be implemented, comprising a cloud layer 4001, a network layer 4002. and a client layer 4003.
  • Program instructions or software applications contained in storage 4005 within the cloud layer 4001 are accessible by servers 4(K»4 that communicate via network 4002 with individual clients in the client layer 4003. It will be understood that the invention can be implemented in connection with configurations and architectures other than cloud configurations, and other than that shown in FIG 40.
  • client operating systems can include known forms of iOS, MacOS, Android, Windows, and Linux. Unix operating systems; and the server operating systems include known forms of Linux/Unix and MacOS operating systems.
  • server operating systems include known forms of Linux/Unix and MacOS operating systems.
  • aspects of the invention described herein can be executed in hardware elements, such as at the server level, or at a microprocessor level, such as within a Field-Programmable Gate Array (FPGA) or an Application-Specific Integrated Circuit (ASIC) constructed specifically to carry out the processes described herein, using ASIC construction techniques known to ASIC manufacturers.
  • FPGA Field-Programmable Gate Array
  • ASIC Application-Specific Integrated Circuit
  • general-purpose processors can be used to execute aspects of the invention.
  • telecommunications devices can include known forms of cellphones, smartphones, and other known forms of mobile devices, tablet computers, desktop and laptop computers, and known forms of digital network components and server/cloud/network/ciient architectures that enable communications between such devices.
  • method aspects of the present invention can be executed within commercially available digital processing devices and systems, such as servers, PC's, laptop computers, tablet computers, personal computer* ⁇ PCs) and smartphoncs or other mobile devices, operating under the collective command of the smartphoncs or computers operating system, such as iOS, Android or Windows, and a computer program product configured in accordance with the present invention, as well as known forms of digital networks, including architectures comprising server, cloud, network, and client aspects, for communications between such devices.
  • digital processing devices and systems such as servers, PC's, laptop computers, tablet computers, personal computer* ⁇ PCs
  • smartphoncs or other mobile devices operating under the collective command of the smartphoncs or computers operating system, such as iOS, Android or Windows
  • computer program product configured in accordance with the present invention, as well as known forms of digital networks, including architectures comprising server, cloud, network, and client aspects, for communications between such devices.
  • computer software can encompass any set of computer-readable programs instructions encoded on a non- transitory computer readable medium.
  • ⁇ computer readable medium can encompass any form of computer readable element, including, but not limited to, a computer hard disk, computer floppy disk, computer-readable flash drive, computer readable RAM or ROM clement, or any other known means of encoding, storing or providing digital information, whether local to or remote from the workstation, PC or other digital processing device or system.
  • Various forms of computer readable elements and media are well known in the computing arts, and their selection is left to the implemented
  • modules and digital processing hardware elements including memory units and other data storage units, including commercially available processing units, memory units, computers, servers, smanphones, tablet computers and other computing and telecommunications devices, including mobile devices.
  • modules include computer program instructions, objects, components, data structures, and the like that can be executed to perform selected tasks or achieve selected outcomes.
  • data storage module can refer to any appropriate memory element usable for storing program instructions, machine readable files, databases, and other data structures.
  • the various digital processing, memory and storage elements described herein can be implemented to operate on a single computing device or system, such as a server or collection of servers, or they can be implemented and inter-operated on various devices across a network, whether in a server-client arrangement, server-cloud-client arrangement, or other configuration in which client devices can communicate with allocated resources, functions or applications programs, or with a server, via a communications network.
  • PIGS. 37A, 37B and 38 arc flowcharts illustrating exemplary method aspects and practices of the invention.
  • the method aspects depicted in this flowchart are examples only; the organization, order and number of operations in the exemplary practices can be varied; and the exemplary practices and methods can be arranged or ordered differently, and include different functions, whether singly or in combination, while still being within the spirit and scope of the present invention.
  • FIG. 37A shows a method 3700 according to an exemplary practice of the invention, including the following operations:
  • Control the content transformation module to apply selected content transformations to digital content directed to the server from the digital content resource, in response to requests by the server.
  • FIG. 37B depicts operations and functionality of the Content Transformation Module according to an exemplary practice of the invention, including the following:
  • the Content Transformation Module is (noting that items shown in parentheses arc, among other aspects, optional in a given practice of the invention): (3710. controllable by the server via a communications channel to selectively request and establish endpoints and users, and to enable selected encryption, on a per-endpoint basis, of content specific to a given digital consumption endpoint. responsive to server-based information representative of endpoint status or endpoint-associated user status);
  • FIG. 38 depicts operations and functionality of the Communications Platform Environment and Communications Platform according to an exemplary practice of the invention, including the following:
  • the Communications Platform Environment and the Communications Platform have the following functionalities (noting that items shown in parentheses are, among other aspects, optional in a given practice of the invention):
  • T he Communications Platform Environment is supported by the server and the content transformation module and organized into three levels, comprising a core services level, a platform modules level, and a platform applications level);
  • the core services level comprises core sen ices usable by platform modules or platform applications; the platform modules level comprises platform-based functional modules operable to utilize selected ones of the core services provided by the core services level; and the platform applications level comprises platform-based application programs operable to utilize selected ones of the platform core services or platform modules);
  • the platform is operable to enable a user of the platform to create and maintain a fictional identity (Persona) for use on selected venues served by the platform, and wherein Persona information is stored independently from user information, so as to preclude unmasking of a real- world user identity based on corresponding Persona information).
  • Persona fictional identity
  • the platform is operable to enable a given user to create separate, different, respective Personas for use with different, respective venues served by the platform);

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention concerne, entre autres aspects, des procédés, des systèmes, des dispositifs et des produits logiciels (produits programmes d'ordinateur) pour créer et maintenir à jour une plate-forme privée et sécurisée de télécommunications et de transactions numériques.
PCT/US2018/032149 2015-03-12 2018-05-10 Plate-forme transactionnelle et de télécommunications sécurisée Ceased WO2018209138A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/612,357 US20200204527A1 (en) 2015-03-12 2018-05-10 Secure telecommunications and transactional platform

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762504211P 2017-05-10 2017-05-10
US62/504,211 2017-05-10

Publications (1)

Publication Number Publication Date
WO2018209138A1 true WO2018209138A1 (fr) 2018-11-15

Family

ID=64105141

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/032149 Ceased WO2018209138A1 (fr) 2015-03-12 2018-05-10 Plate-forme transactionnelle et de télécommunications sécurisée

Country Status (1)

Country Link
WO (1) WO2018209138A1 (fr)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109379176A (zh) * 2018-12-10 2019-02-22 湖北工业大学 一种抗口令泄露的认证与密钥协商方法
WO2020109837A1 (fr) * 2018-11-27 2020-06-04 Pratik Sharma Registre numérique pour transactions
IT201900003677A1 (it) * 2019-03-13 2020-09-13 Fwx Vend Srl Sistema di virtualizzazione dell’interfacciamento e della gestione remota di distributori automatici
CN111831617A (zh) * 2020-07-16 2020-10-27 福建天晴数码有限公司 一种基于分布式系统保证日志数据唯一性的方法
EP3851983A4 (fr) * 2020-02-17 2021-10-20 Beijing Baidu Netcom Science Technology Co., Ltd. Procédé d'autorisation, composant d'autorisation auxiliaire, serveur de gestion et support lisible par ordinateur
US11570153B2 (en) 2020-03-12 2023-01-31 International Business Machines Corporation Virtual machine perfect forward secrecy
CN115695838A (zh) * 2022-10-28 2023-02-03 上海哔哩哔哩科技有限公司 多人连麦方法、服务端、主播端及系统
CN117149802A (zh) * 2023-06-29 2023-12-01 南京维拓科技股份有限公司 工业云应用使用情况统计分析方法
US20240061957A1 (en) * 2022-08-19 2024-02-22 Telesign Corporation User data deidentification system
US12355652B2 (en) * 2022-11-14 2025-07-08 Rakuten Symphony, Inc. Functional testing of NF device
US12475453B1 (en) * 2024-06-28 2025-11-18 Bank Of America Corporation Micro-data transfer using a dual transmission network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110099112A1 (en) * 2007-08-31 2011-04-28 Mages Kenneth G Apparatus and method for conducting securing financial transactions
WO2016145425A1 (fr) * 2015-03-12 2016-09-15 Mine Zero Gmbh Plate-forme de transactions
US20160267475A1 (en) * 2014-01-10 2016-09-15 Tencent Technology (Shenzhen) Company Limited Method and system for secure transactions on a social network platform

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110099112A1 (en) * 2007-08-31 2011-04-28 Mages Kenneth G Apparatus and method for conducting securing financial transactions
US20160267475A1 (en) * 2014-01-10 2016-09-15 Tencent Technology (Shenzhen) Company Limited Method and system for secure transactions on a social network platform
WO2016145425A1 (fr) * 2015-03-12 2016-09-15 Mine Zero Gmbh Plate-forme de transactions

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020109837A1 (fr) * 2018-11-27 2020-06-04 Pratik Sharma Registre numérique pour transactions
CN109379176A (zh) * 2018-12-10 2019-02-22 湖北工业大学 一种抗口令泄露的认证与密钥协商方法
IT201900003677A1 (it) * 2019-03-13 2020-09-13 Fwx Vend Srl Sistema di virtualizzazione dell’interfacciamento e della gestione remota di distributori automatici
EP3851983A4 (fr) * 2020-02-17 2021-10-20 Beijing Baidu Netcom Science Technology Co., Ltd. Procédé d'autorisation, composant d'autorisation auxiliaire, serveur de gestion et support lisible par ordinateur
US11570153B2 (en) 2020-03-12 2023-01-31 International Business Machines Corporation Virtual machine perfect forward secrecy
CN111831617A (zh) * 2020-07-16 2020-10-27 福建天晴数码有限公司 一种基于分布式系统保证日志数据唯一性的方法
CN111831617B (zh) * 2020-07-16 2022-08-09 福建天晴数码有限公司 一种基于分布式系统保证日志数据唯一性的方法
US20240061957A1 (en) * 2022-08-19 2024-02-22 Telesign Corporation User data deidentification system
US12105848B2 (en) * 2022-08-19 2024-10-01 Telesign Corporation User data deidentification system
CN115695838A (zh) * 2022-10-28 2023-02-03 上海哔哩哔哩科技有限公司 多人连麦方法、服务端、主播端及系统
US12355652B2 (en) * 2022-11-14 2025-07-08 Rakuten Symphony, Inc. Functional testing of NF device
CN117149802A (zh) * 2023-06-29 2023-12-01 南京维拓科技股份有限公司 工业云应用使用情况统计分析方法
US12475453B1 (en) * 2024-06-28 2025-11-18 Bank Of America Corporation Micro-data transfer using a dual transmission network

Similar Documents

Publication Publication Date Title
US20200204527A1 (en) Secure telecommunications and transactional platform
WO2018209138A1 (fr) Plate-forme transactionnelle et de télécommunications sécurisée
US12003660B2 (en) Method and system to implement secure real time communications (SRTC) between WebRTC and the internet of things (IoT)
US11936784B2 (en) Attested end-to-end encryption for transporting sensitive data
US10505916B2 (en) Authentication token with client key
US9589144B2 (en) System and method for cryptographic suite management
US10594673B1 (en) Secure interprocess communications between mobile device applications using server-generated keys
US11044082B2 (en) Authenticating secure channel establishment messages based on shared-secret
JP2020502616A (ja) フェデレーテッド・シングル・サインオン（ｓｓｏ）のための非侵入型セキュリティの実施
US9559737B2 (en) Telecommunications chip card
US12278804B2 (en) Systems and methods for generating secure, encrypted communications using multi-party computations in order to perform blockchain operations in decentralized applications
JP5827680B2 (ja) ＩＰｓｅｃとＩＫＥバージョン１の認証を伴うワンタイム・パスワード
US20250021982A1 (en) Digital ecosystem with de-centralized secure transactions and edge ai technology to enable privacy preserved zero-id transactions
US12368723B2 (en) Method and system for managing secure IoT device applications
US10158610B2 (en) Secure application communication system
CN118473683A (zh) 用于跨分布式平台安全流式传输的系统和方法
CN103716280A (zh) 数据传输方法、服务器及系统
US12244743B2 (en) Systems and methods for performing blockchain operations using multi-party computation cohort management groupings
US12256027B2 (en) Systems and methods for performing two-tiered multi-party computation signing procedures to perform blockchain operations
CN106911628A (zh) 一种用户在客户端上注册应用软件的方法及装置
Bameyi et al. End-to-end security in communication networks: a review
Reimair et al. WebCrySIL-web cryptographic service interoperability layer
US12212578B2 (en) Partial payload encryption with integrity protection
Reimair et al. CrySIL: Bringing Crypto to the Modern User
US20250330449A1 (en) Systems and methods for facilitating ingestion of encrypted communications received across cloud computing networks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18798075

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 13/02/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 18798075

Country of ref document: EP

Kind code of ref document: A1