Permission-based control network architecture and system having cellular network components and elements modified to host a permission control scheme designed to facilitate electronic peer-to-peer communication sessions between member computing devices based on cellular communication signals according to a novel cellular communication protocol, and methods of using same

Abstract

In some embodiments, the disclosure provides a method that includes: executing, by a processor of a computing device, application program instructions for displaying an access controller interface element and an access code on a screen of the computing device, the access controller interface element being operatively linked to an access-restricted digital resource; transmitting, by the processor, an access request over a cellular network based on an activity performed with the access controller interface element, the access request including the access code and an ID linked to the computing device; and receiving, by the processor, in response to transmitting the access request over the Internet, access program instructions via the application program for unlocking the access-restricted digital resource for access via the computing device; and executing, by the processor, the access program instructions for unlocking the access-restricted digital resource for access via the computing device.

Description

[Technical Field]

[0001] This application claims priority to U.S. Application No. 17 / 862,402, filed July 11, 2022, U.S. Application No. 11,477,654, filed May 31, 2022, U.S. Application No. 11,533,619, filed May 22, 2022, U.S. Application No. 17 / 750,392, U.S. Application No. 17 / 750,389, filed December 20, 2022. U.S. Application No. 17 / 567,044, filed on May 22, 2022, and issued on November 29, 2022 as U.S. Patent No. 11,516,666; U.S. Application No. 17 / 567,044, filed on December 31, 2021, and issued on August 30, 2022 as U.S. Patent No. 11,432,154; and U.S. Application No. 17 / 567,044, filed on December 31, 2021, and issued on July 12, 2022 as U.S. Patent No. 11,388,601, each of which is incorporated by reference herein in its entirety.

[0002] Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyrights. The following notice applies to the software and data described below and to the drawings forming a part of this document: Copyright, Ari Kahn, All Rights Reserved.

[0003] The subject matter relates to a permission-based control network architecture and system having cellular network components and elements modified to host a permission control scheme designed to facilitate electronic peer-to-peer communication sessions between member computing devices based on cellular communication signals according to a novel cellular communication protocol. [Background technology]

[0004] Typically, cellular communication signals associated with cellular communications may utilize a Basic Call State Model (BCSM) and control points that may govern the setup, progress, and other call-related actions of the communication in an Intelligent Network (IN) (communications network). In one example, if the communication may be a telephony call request originating from a mobile phone, a network switching element (e.g., MSC) may receive the call setup request and then request call processing instructions from a network control element (e.g., SCP / SCF), which may rely on one or more additional devices / systems (e.g., OCS) to determine various aspects of the call, including the decision to proceed with the call. Given that many users prioritize convenience over security, choose easy-to-remember passwords rather than strong, cryptographically-enhanced passwords, and even reuse the same passwords across multiple services, legacy and analog username and password (UNAP)-based security is significantly compromised. Large-scale data security breaches and privacy concerns have eroded online trust, further eroding UNAP methods of accessing services due to increased risk and exposure. Users are also becoming increasingly reluctant to disclose personal data to online entities.

[0005] In the digital universe, for example, to access various networks, users typically must enter an analogue name and password to identify themselves and thereby register and access the service. A username typically includes, but is not limited to, a real name, a pseudonym, an email address, a screen name, and other relatively easy and discoverable personal information about the user. Summary of the Invention [Means for solving the problem]

[0006] In some embodiments, the present disclosure provides various exemplary technically improved methods, one method may include, but is not limited to, establishing, by a processor of a sender computing device, via an application program, a peer-to-peer communication session with a recipient computing device by at least: receiving a personalized Universal Resource Locator link (PURL), including: a domain name associated with a session control internet platform hosting an access permission control schema; at least one first identity linked to the recipient computing device; Here, the PURL is communicatively bound to the authorization control scheme of the session control Internet platform. execute at least one application program instruction to display, based on the PURL, a graphical user interface (GUI) including a plurality of GUI elements, each GUI element programmed to allow a user of the sending computing device to select or input MACRO band parameters associated with the peer-to-peer communications session; transmitting, based on user interaction with the GUI and via Internet Protocol-based communications, the MACRO band parameters and at least one first ID linked to the recipient computing device to a session control Internet platform; receiving a multi-part multi-function address signaling sequence from the session control internet platform in response to transmission of the MACRO band parameters and at least one first identity ID; The MICRO band part corresponding to the MICRO band parameters and The MACRO band part that corresponds to the MACRO band parameter. transmitting, within a peer-to-peer communication session, over a cellular communication network, a session request including data including: the multi-part multi-function address signaling sequence; and At least one secondary ID. wherein, upon sending the session request, based on the domain name and MACRO band parameters, the session activity controlling the internet platform is determined between a first digital wallet associated with at least one first identifier and a second digital wallet associated with at least one second identifier; The microband portion of the multi-part multi-function address signaling sequence is accepted by the cellular communications network and at least one portion of the data is verified to match an expected session record associated with the session control Internet platform.

[0007] In some embodiments, the present disclosure provides various exemplary technically improved methods, one method may include, but is not limited to, at least the following steps: generating a personalized Universal Resource Locator link (PURL) by a session control Internet platform; where your PURL looks like this: communicatively coupled to the authorization control schema and configured to be utilized to establish a peer-to-peer communication session between a sending computing device and a recipient computing device; where the PURL contains: The domain name associated with the session control internet platform that hosts the access permission control scheme, and at least one first identity linked to the recipient computing device; transmitting, by a session control internet platform, the PURL to the recipient's computing device; receiving, by the session control internet platform, after transmitting the PURL to the recipient computing device, a mobile-originated communication having data including: A multi-part multi-function address signaling sequence, including: The MICRO band part corresponding to the MICRO band parameters and MACRO BAND PARTS corresponding to MACRO BAND PARAMETERS AND At least one secondary ID. and tracking, by the session control internet platform, activity between a first digital wallet associated with the at least one first identity and a second digital wallet associated with the at least one second identity based on the domain name and the MACRO band parameters. the microband portion of the multi-part multi-function address signaling sequence is accepted by the cellular communications network; At least one piece of data is verified to match an expected session record. [Brief explanation of the drawings]

[0008] Various embodiments of the present disclosure can be further described with reference to the accompanying drawings, in which like structures are referenced by like numerals throughout the several views. The illustrated drawings are not necessarily to scale, with emphasis instead generally being placed on illustrating the principles of the present disclosure. Therefore, specific structural and functional details disclosed herein should not be construed as limiting, but merely as a representative basis for teaching those skilled in the art how to variously employ one or more exemplary embodiments. [Figure 1]FIG. 1 is an exemplary, non-limiting illustration of a remote control access schema in accordance with at least some embodiments of the present disclosure. [Figure 2] FIG. 2 is an illustrative, non-limiting example of a networking architecture including at least one intelligent element in accordance with at least some embodiments of the present disclosure. [Figure 3] FIG. 3 is an illustrative, non-limiting example of an interworking arrangement in accordance with at least some embodiments of the present disclosure. [Figure 4A] FIG. 4A is an illustrative, non-limiting example of a circuit-switched star logical channel in accordance with at least some embodiments of the present disclosure. [Figure 4B] FIG. 4B is an illustrative, non-limiting example of a packet-switched star logical channel in accordance with at least some embodiments of the present disclosure. [Figure 5] FIG. 5 is an illustrative, non-limiting example of an action button event transition series in accordance with at least some embodiments of the present disclosure. [Figure 6] FIG. 6 is an illustrative, non-limiting example of an action millisecond event timeline in accordance with at least some embodiments of the present disclosure. [Figure 7] FIG. 7 is an exemplary non-limiting illustration of the progression of action event representation abstraction in accordance with at least some embodiments of the present disclosure. [Figure 8] FIG. 8 is manual selection (prior art). [Figure 9] FIG. 9 is an illustrative, non-limiting example of automatic selection in accordance with at least some embodiments of the present disclosure. [Figure 10] FIG. 10 is a multiple action method (prior art). [Figure 11A] FIG. 11A is an illustrative, non-limiting example of the singularity properties of the activity channel method (single activity channel), in accordance with at least some embodiments of the present disclosure. [Figure 11B]FIG. 11B is another illustrative, non-limiting example of the singular nature of the activity channel method (single activity channel), in accordance with at least some embodiments of the present disclosure. [Figure 12A] FIG. 12A is an illustrative, non-limiting example of an action schematic according to at least some embodiments of the present disclosure. [Figure 12B] FIG. 12B is an illustrative, non-limiting example of yet another action schematic, according to at least some embodiments of the present disclosure. [Figure 13A] FIG. 13A is a multiple action method (prior art). [Figure 13B] FIG. 13B is an illustrative, non-limiting example of the singular nature of activity channels in accordance with at least some embodiments of the present disclosure. [Figure 14] FIG. 14 is a comparative graph illustrating results of at least one technology improvement prediction in accordance with at least some embodiments of the present disclosure. [Figure 15A] FIG. 15A is an illustrative, non-limiting example of a processing algorithm utilizing cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 15B] FIG. 15B is an illustrative non-limiting example of a static state processing model matrix utilizing cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 15C] FIG. 15C is an illustrative, non-limiting example of a telephony and natural binary encoded address scheme in accordance with at least some embodiments of the present disclosure. [Figure 16] FIG. 16 is an exemplary non-limiting event / action flowchart of a cellular communication protocol in accordance with at least some embodiments of the present disclosure. [Figure 17] FIG. 17 is an example non-limiting event / action flowchart of an Expectation cellular communication protocol in accordance with at least some embodiments of the present disclosure. [Figure 18]FIG. 18 is an example non-limiting event / action flowchart of a cellular communication protocol in accordance with at least some embodiments of the present disclosure. [Figure 19A] FIG. 19A is an illustrative, non-limiting example of a Circuit Switched Cellular Communication Flash Signaling protocol, in accordance with at least some embodiments of the present disclosure. [Figure 19B] FIG. 19B is an illustrative, non-limiting example of a packet-switched cellular communication flash signaling protocol in accordance with at least some embodiments of the present disclosure. [Figure 19C] FIG. 19C is an illustrative, non-limiting example of a Circuit Switched Cellular Communication Signaling Protocol with automatic routing in accordance with at least some embodiments of the present disclosure. [Figure 20] FIG. 20 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 21] FIG. 21 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 22] FIG. 22 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 23] FIG. 23 is an example non-limiting illustration of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 24] FIG. 24 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 25] FIG. 25 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 26A] FIG. 26A is an illustrative, non-limiting example of an access control network architecture(s) utilizing a cellular signal access control methodology with expected digital key(s) in accordance with the novel communication protocol(s) of at least some embodiments of the present disclosure. [Figure 26B] FIG. 26B is an illustrative, non-limiting example of a binary bot detection process using inference based at least in part on cellular communication signals, according to at least some embodiments of the present disclosure. [Figure 26C] FIG. 26C is an illustrative, non-limiting example of an aspect of a binary bot detection process using inference based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 27] FIG. 27 is an illustrative, non-limiting example of utilizing a cellular signal identity management methodology in accordance with the novel communication protocol(s) and access control network architecture(s) of at least some embodiments of the present disclosure. [Figure 28] FIG. 28 is an illustrative, non-limiting example utilizing anticipated cellular signaling management methodologies in accordance with the novel communication protocol(s) and access control network architecture(s) of at least some embodiments of the present disclosure. [Figure 29] FIG. 29 is an illustrative, non-limiting example utilizing a cellular signal authentication management methodology in accordance with the novel communication protocol(s) and access control network architecture(s) of at least some embodiments of the present disclosure. [Figure 30] FIG. 30 is an illustrative, non-limiting example of an access control network architecture(s) utilizing a cellular signal access control methodology with expected digital key(s) in accordance with the novel communication protocol(s) of at least some embodiments of the present disclosure. [Figure 31]FIG. 31 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 32] FIG. 32 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 33] FIG. 33 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 34] FIG. 34 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 35] FIG. 35 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 36] FIG. 36 is an illustrative non-limiting example of a process based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure. [Figure 37] FIG. 37 is an exemplary, non-limiting illustration of an aspect according to at least some embodiments of the present disclosure. [Figure 38] FIG. 38 is an illustrative non-limiting example of a Star P2P digital communication schema for token redemption (TAP). [Figure 39] FIG. 39 is an illustrative non-limiting example of a Star P2P communication schema for tips, real-world services and / or products (TIPs). [Figure 40] FIG. 40 is an illustrative, non-limiting example of a Star P2P Invoicing URL and Schema. [Figure 41A] FIG. 41A is an illustrative non-limiting example of star micro / macro band signaling notation. [Figure 41B] FIG. 41B is an illustrative non-limiting example of a Star Micro / Macro Band Control / Session Record Keeping Matrix. [Figure 41C] FIG. 41C is an illustrative non-limiting example of a star micro / macro band permission verification flow chart. [Figure 42] FIG. 42 is an illustrative non-limiting example of a Star Micro / Macro Band Expectation Flowchart. [Figure 43] FIG. 43 is an illustrative non-limiting example of a Star Micro / Macro Band communication session (e.g., transaction) flow chart. [Figure 44] Figure 44 is an illustrative non-limiting example of the Star Internet of Things Token Payment Schema (IOT). [Figure 45] FIG. 45 is an illustrative, non-limiting example of a Star Cellular Authorized Bank Switched Session (e.g., transaction). DETAILED DESCRIPTION OF THE INVENTION

[0009] Various detailed embodiments of the present disclosure, taken in conjunction with the accompanying figures, are disclosed herein; however, it should be understood that the disclosed embodiments are merely exemplary. Additionally, the examples provided in connection with the various embodiments of the present disclosure are illustrative and not limiting.

[0010] Throughout this specification, the following terms shall have the meanings expressly associated therewith unless the context clearly dictates otherwise. As used herein, the phrases "in one embodiment" and "in some embodiments" do not necessarily refer to the same embodiment(s), although they may. Additionally, as used herein, the phrases "in another embodiment" and "in some other embodiments" do not necessarily refer to different embodiments, although they may. Thus, as described below, various embodiments can be readily combined without departing from the scope or spirit of the present disclosure.

[0011] All systems, platforms, devices (including cellular service-enabled computing devices such as mobile phones), components, elements, and corresponding methods, rules, principles, code, and policies disclosed herein, programmed into associated hardware, software, or combinations of hardware and software, and collectively formulated, may be referred to herein interchangeably as the STAR Operating System (*OS or *O / S). For example, the STARKEY Platform (also referred to herein as the STAR Platform and / or STARPAY Platform), the STARGATE Protocol, the STAR BAND Signaling Protocol, the STAR Cellular Access Control Rules / Code / Policies, and other STAR components referenced herein may be programmed to execute and / or operate in accordance with the *O / S. In some cases, the connection of one entity of the *O / S to another entity may operate physically or logically on the same network element or local area network, and two or more entities of the *O / S may operate on a single hardware platform and / or network. Also, the connection between STAR entities may be remote, between separate network elements, or via network connections spanning distances. Each embodiment may use different hardware, software, and interconnection architectures to achieve the described exemplary functionality of the *O / S.

[0012] Some exemplary non-limiting technical problems addressed herein

[0013] One technological problem addressed in this disclosure is that users' online experiences are being subject to increasingly invasive, interruptive, and universally abhorrent digital content (e.g., digital advertising). For example, some content providers intentionally irritate online users with a large number of digital advertisements and then extort monthly payments from users solely for software solutions intended to relieve online users from the very spam created by the digital content providers.

[0014] Another technical issue addressed in this disclosure is that while many Internet browsers (application programs) may offer digital ad-blocking technology to suppress online advertising, some browser creators themselves, in suppressing unwanted digital content (e.g., digital advertisements), may obfuscate and / or make it difficult for online users to configure their Internet browsers to reduce and / or eliminate tracking of their online activities, and / or may make it difficult for online users to configure their Internet browsers to reduce and / or eliminate tracking of their online activities, and / or may offer digital ad-blocking technology to suppress online advertising so that online users can reduce and / or eliminate tracking of their online activities and get the same online experience without giving up their online privacy.

[0015] Yet another technical issue addressed in this disclosure is that digital advertising may also take the form of "clickbait," images and / or links that appear to lead to newsworthy stories and / or interesting videos, when in fact various online technologies may enable bad actors to cleverly design deceptive digital advertisements in order to extract and / or steal personal information and / or conduct ransomware attacks that may undermine users' trust in online publishing.

[0016] Yet another technological issue addressed in this disclosure is that online users may perceive a lack of online privacy and increase their distrust of digital technologies, for example, due to the frequency of large-scale data security breaches that may have dramatically reduced the level of trust users have in their data and / or activities (e.g., electronic payment activities) protected by digital security measures / technologies utilized by unknown and / or known third parties.

[0017] Yet another technical problem addressed in this disclosure is that online technologies typically lack the ability to effectively execute single online transactions, such as executing digital payments for a single online article of interest rather than an entire online publication, a single music track rather than an entire album, a Single Service Unit (SSU), and similar units of other digital content, and / or digital services, and / or physical services with digital components, and / or any combination thereof.

[0018] Yet another technical issue addressed in this disclosure is that online experiences currently still lack micro-commerce capabilities (e.g., ISO 9001:2005 standard published by the International Organization for Standardization). One or more minor units of one or more currencies as defined by the 4217 standard (e.g., one or more US cents ... For example, traditional bank switches that charge high transaction fees do not support small charges. For example, but not limited to, digital technologies related to cryptocurrencies also lack micro-commerce capabilities. Technical issues with digital technologies related to cryptocurrencies may be due to the technical complexity of setting up and / or managing cryptocurrency wallets, which typically require users to bear responsibility for safeguarding their digital keys. For example, but not limited to, the computational intensity and / or digital resource demands (e.g., CPU / GPU processing power requirements, computer memory demands, power demands, etc.) associated with executing and / or recording digital transactions in cryptocurrencies.

[0019] Furthermore, while the promise of cryptocurrencies is decentralization to democratize digital transactions (such as currencies), the cryptocurrency exchanges that facilitate these transactions are necessarily centralized and typically vulnerable to various cyberattacks. For example, it has been reported that one-third of cryptocurrency exchanges have been hacked, resulting in the theft or loss of millions of cryptocurrencies worth billions of dollars.

[0020] Yet another technical issue addressed in this disclosure is that cryptocurrencies are subject to volatile fluctuations in valuation and the potential for market manipulation by numerous bad actors utilizing a variety of digital technologies, which could lead to significant and substantial losses of fiat currency. Yet another technical issue addressed in this disclosure is that according to the BCSM and control points / elements that may govern the setup, progress, and charging of communications in a typical Intelligent Network (IN) (e.g., the network architecture specified in the ITU-T Q.1200 series recommendations), a typical IN is limited because it applies pro rata call charges only when the communication is a telephone call, where the total billing amount is calculated based on the total call duration (e.g., seconds or minutes consumed). In one case of such a typical IN, the charging and / or control elements are programmed to provide subsequent quotas if the call continues beyond the initial quota. Alternatively, in another case of such a typical IN, the initial quota may also be the final quota, and the call may be disconnected (released) when it is exhausted. For example, upon determining that credit sufficiency exists based on the charges associated with the requested call destination, identified by address signaling (e.g., Called Party Number (CdPN)) according to the BCSM, a typical IN processing element (e.g., a charging element / system) then determines an initial service quota (e.g., maximum allowable call duration) and an instruction to proceed with switching and routing the call to the destination. Additionally, in a typical IN, the control element may arm specific trigger detection points (TDPs) that may be encountered during the course of a communication to receive an alert, e.g., arm TDP-R (TDP armed as Request), which, when encountered, will either interrupt the communication process awaiting further instructions from the control element, or to be notified, e.g., arm TDP-N (TDP armed as Notification), which simply notifies the control element when an event occurs. In one embodiment, these trigger detection points may be statically armed and configured in a subscriber profile (e.g., in the O-CSI).

[0021] In one embodiment, a typical control element of a typical IN controls and / or monitors calls, and thus controls charging in substantially real time, by issuing a Request Report BCSM event (RRBE) to be notified when an outgoing call is answered (DP O_Answer) and when the call is released (DP O_Disconnect), and then calculating the total charge to be applied based on the call duration. Furthermore, the control element and / or charging element of the typical IN may be programmed to instruct a typical switching element to perform an Apply Charging (ACH) function, and the typical switching element may begin or continue to monitor the call duration. When the initial quota is exhausted or the call is released, the switching element may then provide an Apply Charging Report (ACR) to the typical control element. Upon receiving the ACR, the typical management element or charging element can process and generate a call data record (CDR) to calculate the total charge to be applied to the call based on the call duration. Thus, yet another technical problem addressed in this disclosure is the ability of a cellular device (e.g., a smartphone) to signal to a cellular network operator (e.g., a typical IN charging element) the charges that apply to a call or service, thereby controlling / generating the process of recording / generating / applying the charges (e.g., CDRs) in an electronic data record associated with the cellular device. Yet another technical problem addressed in this disclosure is the lack of a mechanism for automatically recalling and / or canceling a transaction once it has been submitted.

[0022] Yet another technical problem addressed in this disclosure is that many users may become trapped into recurring subscriptions to services they do not intend to subscribe to and / or do not understand the meaning or terms of their subscription because the service terms and applicable fees are not clearly presented and / or made clear, for example, via Premium Short Message Service (PSMS) communications. For example, in order for a typical IN network to apply differentiated billing rates, the network must assign short address codes to messaging services and utilize alternative bearers and services, such as PSMS, that can be associated and utilized to apply different rates (usually premium rates) to users who use the messaging services. However, such Premium SMS (PSMS) rated billing elements in typical INs are not programmed to recognize the short code itself as a trigger that lists and consequently indicates the applicable fees and charges. As a result, one technical drawback of typical IN PSMS rated billing elements is the need for metadata transferred in the SMS body to inform users of the applicable fees for the selected service. Typically, such metadata can be insufficient to inform users. Additionally, another technical drawback of the typical PSMS model is that the desired rates and fees to be applied are communicated not by the cellular device associated with the user / consumer, but by a third-party PSMS platform provider that instructs the operator's IN billing system on what rates to apply based on the service being requested, making billing outside of the user's control. Yet another technical issue addressed in this disclosure is that internet-originated mobile phone billing, such as direct carrier billing (DCB), can allow third-party charges for digital content and services to be assessed against cellular accounts without the control and transparency given to the user and without originating from the user's associated cellular device. For example, DCB can be considered an internet backdoor into carrier billing systems, allowing transactions described as internet-originated (IO) billing. For example, DCB authenticates cellular devices using two-factor authentication (2FA) methods, such as 2FA SMS, which sends a one-time passcode (OTP) over the cellular network and requires the user / customer to resubmit it to an access control platform over an internet connection to verify the identity of the cellular device (e.g., MSISDN). While on the surface, 2FA appears to provide an additional layer of security, as discussed in this document, the use of 2FA can create numerous technical drawbacks, for example, by introducing additional steps and clicks (e.g., six additional clicks required to process a single 2FA, such as opening an SMS, entering a four-digit or more OTP into an internet application (IAPP), and clicking submit). An additional technical drawback associated with 2FA SMS is the use of the SS7 messaging network, which may have inherent security vulnerabilities. For example, the SS7 signaling network may allow malicious actors with access to SS7 peering points to redirect and / or intercept these mobile-terminated signals carrying authentication codes. Such security drawbacks associated with the use of 2FA over the SS7 signaling network may typically be caused by the source of the SS7 messages not being authenticated, thus allowing critical network control messages to be injected into the SS7 network from entities posing as cellular devices (e.g., mobile phones) and / or switching and control elements.For example, malicious actors could inject and fake location updates for cellular devices (or overwrite subscriber profile information such as HLR) to hijack cellular routing and covertly intercept phone calls and SMS.

[0023] For example, man-in-the-middle (MITM) attacks have caused the US National Institute of Standards and Technology (NIST) to reverse its recommendation and support of such 2FA services. Thus, at least in some cases, cellular 2FA may compromise security while purporting to enhance it, given that anyone with sufficient knowledge to exploit SS7 vulnerabilities could potentially present another person's MSISDN (the MSISDN of a computing device (e.g., a mobile phone) associated with that person), intercept authentication codes, and transact illegally with the now-compromised (hijacked) mobile phone account. Additionally, while in at least some instances a cellular operator / carrier may be able to probe network traffic to extract the device ID of a cellular device, for example, by inspecting the cellular data source IP (Internet Protocol) address and correlating the cellular data session identifier with cellular device ownership and identification data (e.g., MSISDN) stored by the network element(s), at least one technical drawback of such an approach is due to the user's requirement to connect to the Internet via a mobile packet backbone network (MPBN) using cellular packet data bearers that are not available to those using WIFI connections, where the originating traffic does not necessarily traverse the cellular network or uniquely identify the sending cellular device.

[0024] For example, in at least some instances, an additional technical drawback recognized herein is that once a cellular device is authenticated, DCB will typically be implemented using premium rate SMS communications (PSMS), which may also be vulnerable to abuse (e.g., security breaches, vishing attacks, etc.). For example, when a user selects the pay with mobile / cell phone option (e.g., see FIG. 10), the DCB platform typically sends an SMS originating from a premium rate short code address (the address of the DCB messaging platform) to the user / consumer's cellular device. Typically, the SMS will include the transaction price in the SMS message body and be programmed to request the recipient (e.g., the consumer) respond in the affirmative (e.g., "Y") to confirm the transaction. Furthermore, additional technical disadvantages recognized herein include that when the DCB platform receives the SMS response confirmation, the DCB platform may not be able to reliably determine that the SMS response confirmation was sent from the cellular device, and the DCB platform accepts and trusts that the SMS response confirmation came from the cellular device, and the DCB platform cannot reliably determine that the SMS response confirmation came from the cellular device, and the DCB platform cannot reliably determine that the SMS response confirmation came from the cellular device, and the DCB platform cannot reliably determine that the SMS response confirmation came from the cellular device, and the DCB platform accepts and trusts that the SMS response confirmation came from the cellular device, and the DCB platform accepts and trusts that the SMS response confirmation came from the cellular device, and the DCB platform accepts and trusts that the SMS response confirmation was sent from the cellular device; Thus, the SMS reply confirmation, which represents the consumer's explicit permission to complete the transaction, may be irrelevant because it can itself be compromised by a Trojan (malware) that intercepts and responds in the background without alerting the consumer / user. Upon receiving the SMS reply confirmation to the PSMS, the DCB platform can complete the access action by instructing the mobile operator / carrier's billing element (e.g., carrier billing system) to, for example, debit the transaction amount from a prepaid mobile phone account associated with the user's mobile phone device or charge the transaction amount to a mobile phone account associated with the user's mobile phone device. As detailed herein, at least some of the technical shortcomings addressed herein are due to numerous security vulnerabilities associated with one or more of the following steps of a typical DCB process: Users must manually select mobile billing as their payment method. Users must manually enter their mobile phone number (such as MSIDN) and thereby expose it to third parties. User will have to wait for the 2FA SMS code on their mobile / cell phone to verify the MSISDN. The user must switch application context to open the received SMS and memorize the one-time passcode (OTP) it contains. The user must invoke the OTP and manually re-enter it in the Internet Services application screen. The user then needs to wait for PSMS to accept the transaction price. The user must manually reply to confirm the PSMS transaction amount, after which the user can consume content or access services.

[0025] For example, even when carrier networks utilize packet probing to authenticate cellular IDs, the process utilizes 2FA, resulting in cellular billing transaction sequences involving over 20 manual keystrokes and clicks. Even after a cellular device is authenticated, subsequent DCB transactions may require at least six or more manual user-initiated inputs. Additionally, steps 6 and 7 above of the DCB protocol are typically mandated to satisfy regulatory requirements governing user opt-in and purchase confirmation when selecting payments for third-party content and services directed to a cellular account. Yet another technical drawback is that the only detailed record of a transaction is the messaging content in the internet-originated SMS body, which mobile operators typically do not store and / or report in itemized billing (e.g., account records). Therefore, SMS reply confirmations may be fraudulent (e.g., hijacked by malicious actors). Furthermore, without encapsulating and forwarding messaging content along the SMS transaction path (e.g., if the DCB transaction record is transient and missing), mobile operators / carriers' typical IN may be forced to rely on third-party metadata. For example, a cellular account may simply itemize / describe a DCB transaction as an SMS incurring the premium cost without providing an authoritative and irrevocable cellular data record capturing the transaction amount confirmed by the user at the time of purchase. In at least some cases, such incomplete billing records could result in many disputed DCB transactions being recorded on the mobile account. Therefore, because DCB is under third-party billing control, it is inherently vulnerable and requires extensive fraud detection and prevention measures. Furthermore, such security measures typically assume that users will audit their billing statements and report suspicious transactions. As a result, many fraudulent DCB deductions go undetected and unreported, costing consumers untold billions of dollars in unauthorized transactions, while relatively small amounts go undetected and affect millions of unsuspecting online users in a practice known as "skimming."

[0026] Yet another technical problem addressed in this disclosure is the need for a user to verify their cell phone number and use a service (e.g., Meta, Twitter, TM , Signal TM Facebook by (Signal Messenger LLC.) TM and WhatsApp TM(e.g., providing cell phone numbers in plaintext, without encryption, for delivery of 2FA codes to register for and access mobile phones and other services may jeopardize privacy and security. For example, because 2FA relies on transmitting a Mobile Terminating (MT) signal to associated devices, requiring cell phone IDs (e.g., MSISDNs) to be presented in plaintext to address and deliver one-time passcodes (OTPs) to users to verify their cell phone IDs, 2FA systems may store millions of real digital identities (e.g., mobile phone numbers), thereby exposing them to data breaches and other activities (e.g., spam, phishing) by bad actors, and potentially allowing internet companies to share users' personal information with third parties without their knowledge, control, and / or consent. Yet another technical issue addressed in this disclosure is that users who wish to avoid providing their mobile phone number for registration may be able to purchase fake, or "burner," phone numbers. Typically, fake phone numbers are used only once, after the user receives a verification code, after which the number ceases to exist or is reassigned to another user.

[0027] Yet another technical problem addressed in this disclosure is the existence of electronic services, such as those offered by companies such as PVACreator (www.pvacreator.com), that can automatically bulk register bots for online services and social platforms and potentially utilize bots to generate fictitious accounts associated with other bots. Yet another technical drawback is that digital content publishers who want to monetize their content may try to lure users into recurring weekly, monthly, or yearly subscriptions, since charging for shorter subscription periods and smaller amounts of content is typically not technically profitable for online content providers, as it may require more complex technical setup and maintenance of electronic / digital resources. This includes electronic / digital resources with limited access that prohibit operating electronic access on an SSU basis and involve prohibitive fixed costs for users / consumers / entities that are not technically sophisticated and / or cannot build the necessary technical architecture. For example, individual and small content creators are typically forced to distribute their works through content curators and aggregators, and some music streaming services may pay composers as little as $0.00001 (one-thousandth of a penny) per song.

[0028] Another technical drawback of digital subscription technology is that digital subscription paywalls typically result in single-digit conversion numbers (only 5% subscribe, according to a survey conducted by DIGIDAY™) because they lack a sufficiently technology-driven interactive experience to convert and retain users. As such, subscription-based services are heavily biased in favor of large-scale national and multinational news organizations and content creators, further undermining the democratization of digital publishing. Yet another example, although long felt over at least the past 30 years, is an unmet need for technology development relevant to this disclosure, without limitation, identified by Micropayments, Abridged (Ryan Shea, medium.com / radartech / micropayments-abridged-2f110302677c): "A functioning micropayment system allowing instant and infinitesimal transactions of less than $1 USD is widely regarded as the holy grail of web monetization. ...Until now, fundamental issues around usability, psychology, and economics have been neglected. These issues must be resolved if micropayments are to be successful." Yet another example, long felt over at least the past 30 years, is the unmet need for technological development related to this disclosure, identified without limitation by *The Babbage of the web* (Ted Nelson, *The Economist*, December 7, 2000): The increasing democratization of publishing meant that readers expected to pay for what they read and that the authors of the most popular documents would be compensated accordingly.

[0029] As yet another example, although long felt over the past 30 years at least, the unmet need for technological development relevant to this disclosure has been identified without qualification by Peppercoin micropayments (Ronald L. Rivest, Proceedings Financial Cryptography, 2004): "We see the introduction of efficient micropayments into the world of Internet e-commerce as potentially as important as the invention of metal coins by the Lydians in 640 BC." Yet another example, a long felt, over the last 30 years at least, unmet need for technological development related to this disclosure is, without limitation, Shouldn't We All Have Seamless Micropayments By Now? (Alvaro Dominguez, wired.com / story / shouldnt-we-all-have-seamless-micropayments-by-now / ): “The founders of the web fully expected some form of digital payments to be essential to its functioning. But nearly 30 years later, we're still waiting. … In the absence of a digitally native micropayments system, content creators are forced to rely on advertising. Again, this is a losing battle for all but the biggest players. Even Facebook and YouTube, the clear winners in the digital ad economy, must operate at scale, employ a great deal of surveillance, and subject their systems to minimal human oversight in order to make ad funding work. Content creators chase eyeballs and a share of ad dollars on these giant platforms, whose business models reliant on virality, misinformation, and outrage. … As if that weren't bad enough, an intrusive and bloated layer of ad tech slows the internet and serves as a potential vector for malware. Plus, click fraud is rife in the online advertising business. The whole thing could become a house of cards.” Yet another technical problem addressed in this disclosure is that electronic exchanges trading in fiat, digital, and / or cryptocurrencies are typically, and often inevitably, centralized (CeFi—Centralized Finance), require product and / or wallet disclosure, and are consequently vulnerable to cyberattacks from malicious actors (e.g., phishing, spam, etc.). In some embodiments, this can result in a need for a simple, fast, and secure way to switch and transfer digital currencies directly between users on a peer-to-peer basis.

[0030] Yet another technical issue addressed in this disclosure is the problem of fraudulent use of stolen credit / debit cards (collectively, "financial instruments") in online transactions, which can cost the industry and consumers significant amounts of money, for example, in risk management surcharges, levies, and insurance. For example, a typical artificial intelligence (AI)-based fraud detection system may identify what appears to be a fraudulent or suspicious transaction, which may actually be a legitimate transaction, and then initially deny it, pending consumer approval (e.g., an SMS fraud alert sent to the cardholder's mobile phone requesting a YES / NO verification response). This may require a legitimate customer to pause (e.g., wait a few minutes) before submitting a second, duplicate transaction. Typical AI systems may be inept at predicting what is legitimate, even though it deviates from typical purchases. Described herein are exemplary, non-limiting technical solutions, namely, cellular network components and elements modified to a host access control schema designed to translate and / or facilitate cellular communication signals in accordance with a novel cellular communication protocol with multi-part multi-function address signaling, including access control network architectures and systems, and methods of use thereof.

[0031] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing access control network architectures and systems having cellular network components and elements, such as control and / or charging elements, modified into a host access control scheme designed to translate and / or facilitate cellular communications signals according to a new cellular communications protocol with multi-part multi-function addressing, and methods of use thereof. In at least some embodiments, the access control scheme of the present disclosure may be designed to process mobile-originated address signals transmitted / or originated according to a new cellular communications protocol (also interchangeably referred to herein as the STAR BAND signaling protocol) using multi-part multi-function address signaling that includes multiple address signal portions designed for multiple functions. The various schemes (e.g., sequences, strings, headers) of the multi-part multi-function address signaling may be collectively referred to herein as the "STAR Cellular Access Control Protocol / Code / Policy."

[0032] In at least some embodiments, as described in more detail below, for example, by a computing device (e.g., device 100 of FIG. 1) having cellular signaling capabilities (e.g., a mobile phone), for example, without limitation, when a user dials and / or transmits (via the computing device) such a multi-part multi-function access control sequence, an exemplary multi-part multi-function address signaling sequence (also interchangeably referred to herein as a STAR Band Signaling Sequence) may be displayed to the user and may include at least three parts (considering from the first address signal in the address signal sequence): Part-1 / Part-2 / Part-3. a first part (Part-1) designed to perform a first function; a second part (part 2) designed to perform a second function; Part 3 (Part 3) was designed to fulfill a third function. The symbol " / " is used in the above notation merely as a logical separator between parts of the above exemplary multi-part multi-function access control sequence; the parts may be dialed sequentially without a separator signal, or may be typed in sequence (e.g., as an address in cellular communications (e.g., call, SMS, etc.)). In at least some embodiments, at least two of the first function, second function, and third function are different. In at least some embodiments, the first function, second function, and third function are different.

[0033] In at least some embodiments, without limitation, the first part (part-1) may include address signals corresponding to at least one symbolic routing prefix (e.g., STAR (“*”)), and thus serve a first function (i.e., network routing function) that is an element(s) of a cellular network, converted as detailed herein, and may be programmed to recognize as a symbolic network routing prefix and route the entire multi-part multi-function address signaling sequence or modified / parsed multi-part multi-function address signaling sequence (e.g., a subsequence consisting of part-2 and part-3, a subsequence consisting of part-2, a subsequence consisting of part-3, a derived subsequence derived from at least one of part-3) to at least one network destination, such as, but not limited to, at least one network destination, such as, but not limited to, the access control platform 210 and / or the STARKEY platform of FIG. 2 , as detailed in FIG. 26A and other figures herein.

[0034] In at least some embodiments, an exemplary multi-part multi-function address signaling sequence may correspond to, for example, but not limited to, a dialing sequence (e.g., a user dials utilizing a native mobile phone APP or a user gives permission to a native mobile phone APP to dial, e.g., with click-to-call functionality) and / or an SMS destination address of an exemplary multi-part multi-function access control sequence. Part-1 / Part-2 / Part-3 are represented in the format *NNNXYXYXYXYXYXY, where the star (*) corresponds to the address signals that make up Part-1, NNN corresponds to the address signals that make up Part-2, and XYXYXYXYXYXY corresponds to the address signals that make up Part-3. It is understood that in at least some embodiments, references to a user manually dialing various address signaling sequences / strings in this disclosure are exemplary, and that the same or sufficiently similar principles of operation and communication are also applicable when a user enters a multi-part, multi-function access control sequence as a dial destination address or SMS destination (e.g., user input using an SMS messaging app), as multi-part signaling sequences may be entered and dial addressed automatically (e.g., with a click-to-call feature, or via programmable SMS, etc.), particularly when the cellular-enabled device is distinct from a computing device (e.g., a laptop, a terminal without cellular signaling capabilities). In at least some embodiments, an exemplary multi-part multi-function address signaling sequence may correspond to an address sequence (e.g., cellular telephony address, SMS address) of an exemplary multi-part multi-function access control sequence, including but not limited to, part-1 / part-2 / part-3, in the following format: Routing Symbol in Figure 1 / Access Code / RAN Sequence in Figures 26A and 26B, where it should be understood that the symbol " / " is used in the above notation merely as a logical separator between parts of the above exemplary multi-part multi-function address signaling sequence, and that the parts may be dialed in sequence without a separator signal.

[0035] In at least some embodiments, the above exemplary multi-part, multi-function access control sequence may be presented, for example, as part of the access controller interface element 103 of Figure 1 as part of a process for accessing a restricted resource, or as part of an access and authentication process that is communicatively coupled to the star challenge 2603 of Figure 26A. For example, the cellular network control schema 121 of Figure 1 may be part of a cellular network (e.g., a typical IN charging element). Thus, when a cellular service-enabled computing device (e.g., a mobile phone / cell phone) uses a mobile-originated cellular communication protocol to transmit / originate an access request including the above-described exemplary multi-part multi-function address signaling sequence corresponding to the multi-part multi-function access control sequence along the cellular signaling path 105 of FIG. 1, the cellular network-hosted access control schema 121 may then recognize Part-2 of the above-described exemplary multi-part multi-function access control sequence, also interchangeably referred to herein as a "microband," as a charge to be applied to at least one of the call, product, or service, thereby controlling / causing a process of recording / generating / applying a charge (e.g., CDR) to an electronic data record (e.g., a data record in the cell wallet 490 of FIG. 4) (e.g., a SIM-associated prepaid account) associated with the cellular service-enabled computing device (e.g., a mobile phone / cell phone) and / or controlling / causing a process of debiting a corresponding amount from the cell wallet. In at least some embodiments, part-2 of an exemplary multi-part multi-function access control sequence may correspond to one or more minor units (e.g., one or more US cents) of one or more currencies defined by the ISO 4217 standard.

[0036] In some embodiments, e.g., with reference to FIG. 1 , for example, but not limited to, after the cellular network control schema 121 of FIG. 1 performs or causes to be performed an action(s) in accordance with a desired function associated with part-2 of the exemplary multi-part multi-function address signaling sequence, the cellular network control schema 121 of FIG. 1 and / or one or more cooperating network elements may be programmed to route / transport, in whole or at least, one particular portion of the exemplary multi-part multi-function address signaling sequence (e.g., part-2 with part-3, part-3 only) corresponding to and including part-3 of the multi-part multi-function access control sequence, and at least one identity associated with a cellular service-enabled device (e.g., MSISDN), and at least one remote destination, for example, but not limited to, the remote Internet access control server 111 of FIG. 1 or the STARKEY platform, as described in more detail with respect to, e.g., FIGS. 26A-28 and other figures herein.

[0037] In at least some embodiments, Microband (Part-2) address signaling may be formatted to support a zero charge option that may be signaled and recorded in the cellular CDR (certificate): *000RAN (RAN is Part-3). In at least one non-limiting embodiment, zero microband signaling may enable at least one of the following: billing cancellation, payment authorization cancellation, and credit issuance (e.g., a company paying a microcharge / tab for all users). For example, in at least one non-limiting embodiment, utilizing a mobile carrier's zero microband signaling and / or reverse charge data service capabilities may enable a website or URL owner to cover the cost of data used by visitors to their site, such that consumers can visit, view, and / or transact on their website and / or advertisements without incurring any cost to their mobile phone account balance, including being able to reach the website with no airtime / data balance at all. For example, in at least one non-limiting embodiment, utilizing a mobile carrier's zero microband signaling and / or reverse charge data service capabilities may enable, without limitation, reverse charge SMS messaging, in which replies to an SMS are billed to the carrier that sent the message, rather than to the consumer who requested a response to the SMS.

[0038] In at least some embodiments, Part 3 of the exemplary multi-part multi-function access control sequence may include a randomly generated sequence and series of numbers, including but not limited to a Star Random Challenge (e.g., RAN) and a Star Random Challenge & Response (described further herein) that is processed at the at least one remote destination to cause an action(s) to be performed or executed in accordance with an associated desired function, or ...

[0039] In at least some embodiments, Part-3 may include a randomly generated sequence of numbers (e.g., The Star Challenge (e.g., RAN)), which the access control platform will generate and process as detailed herein. In at least some embodiments, the randomly generated digit sequence of Part-3 may be generated based on a logarithmic function, where the exponent is the product of the length (X number of digits) of Part-3 (e.g., 10^X), and is referred to interchangeably herein as a "logarithmic band."

[0040] In at least some embodiments, various aspects of the creation, processing, utilization, transmission and / or modification of the exemplary multi-part, multi-function access control sequence, including Part-1 / Part-2 / Part-3, may be performed in accordance with one or more methods / principles / rules disclosed herein and by one or more systems, platforms, access control network architectures, elements, and / or components disclosed herein. For example, the signal may be determined based on the following non-limiting logic: If the received total signal (STOTAL) is greater than the minimum expected length (SMICRO) (e.g., a MICRO BAND signal containing 3 digits) and less than the maximum expected length (SRAN) (e.g., a MICRO BAND signal and a RAN signal containing 15 digits), then such a signal is referred to interchangeably herein as a "MACRO BAND" signal. For example, in a non-limiting embodiment: The MACRO signal can be calculated as follows if: ((STOTAL > SMICRO) & (STOTAL < SRAN)). In at least some embodiments, the exemplary signal-to-rate conversion in a packet-switched network embodiment may be accomplished by, for example, referencing the SIP URI / To String header and performing string operations that parse each part of an exemplary multi-part multi-function access control sequence, such as the following JavaScript code showing parsing part 2: An example corresponding to a fixed triplet notation (NNN) and knowing a particular exemplary STAR BAND signaling protocol as shown in Table 1: parseInt(SIP_To.substring(1,4)). [Table 1]

[0041] For example, and without limitation, assuming that the address signals of an exemplary multi-part multi-function address signaling sequence correspond to a multi-part multi-function access control sequence of S (e.g., S=*099927485617253), appropriate substring extraction and integer conversion functions detailed herein and performed, for example, by an MNO billing element(s) would extract the "099" and insert those MICRO BAND signals (e.g., from string to integer form) into a matching $0.99 charge (e.g., as a CDR) as disclosed herein. In one non-limiting embodiment, the MNO element(s) may use a wildcard routing entry in the network switching element table(s) to route all undefined star dialed (e.g., with a "*" prefix) numbers to the STARKEY access control platform, while allowing the network charging element(s) to extract the MICRO BAND signaling for charging purposes, and all additional signaling (e.g., Part-3) to the right of the MICRO BAND signaling can be transparently forwarded to the STARKEY access control platform for internal calculations without MNO interpretation.

[0042] In at least some embodiments, the present disclosure of various strings and numeric operations (which may be collectively referred to herein as the "STAR Cellular Access Control Protocol / Code / Policy") may therefore enable an MNO element(s) to deliver dynamic charging to the Internet, where, for example, without limitation, the disclosed buttons remotely control core MNO processes (e.g., the MNO's billing procedures). In at least some embodiments, part-2 and part-3 of the multi-part multi-function access control sequence of the present disclosure may be further delimited using one or more symbols (e.g., "*", "#", etc.) as shown, but not limited to: *099*099927485617253 (*Part-2*Part-3) *000*099927485617253 (*Part-2*Part-3) *9999*099927485617253 (*Part-2*Part-3) *099#099927485617253 (*Part-2#Part-3) etc. The above example schema provides both visual and computational markers that separate multi-part signaling bands in accordance with STAR cellular access control protocols / codes / policies, and can also provide a signaling implementation that allows for fixed lengths, variable lengths, or both, that can be utilized to provide dynamic resource access for multi-resource authentication and authorization, including dynamic charging.

[0043] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing MICRO BAND and / or MACRO BAND communication between multiple digital wallets (e.g., 2, 3, 5, 6, N, etc.). In at least some embodiments, a user may dial (and / or send an SMS or USSD) a symbolic routing prefix to numbers reciting a MICRO BAND, followed by a MACRO BAND, where the former is immediately deducted from their cellular wallet, for example, without limitation, as detailed herein, and the latter is transferred from the sender's Internet wallet to the recipient's Internet wallet, where the sender computing device has been authenticated, for example, by one or more methods detailed herein, such that the identity of the sending device is stored in the Internet application (e.g., IAPP, browser, etc.), thus enabling the systems / components / elements / devices of the present disclosure to utilize multi-part MICRO BAND(NNN) / MACRO BAND(XXX) address signaling.

[0044] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein, for example, but not limited to, by utilizing mobile-originated FLASH HOOK signaling, whereby communications may occur in sub-second calls that are instantly connected and disconnected. In one non-limiting embodiment, generating a session ticket (e.g., CDR) at an originating mobile switch in an amount equivalent to a MICRO BAND address signal (digits).

[0045] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein, for example, but not limited to, by utilizing an exemplary permission-based communication protocol of the present disclosure, which may be configured to uniquely synchronize and correlate such flash hook cellular communication session events; and a second internet wallet destined for the recipient, which enables digital tokens (e.g., digital assets representing fiat currency or cryptocurrency) to be seamlessly and securely switched in a peer-to-peer signaling communication session over a time-efficient (e.g., nanosecond, millisecond, microsecond) signaling protocol at marginal cost with reduced computing and network resources.

[0046] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing an exemplary Star TAP communication signaling protocol that may be configured to enable any Star Recipient to instantly redeem their Star Tokens for fiat by transferring them to other people willing to exchange the tokens for cash and for use by friends, family, and the like, using a cloud-hosted permission-based control scheme.

[0047] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing an exemplary TAP communication signaling protocol, which enables users to exchange Star digital assets (e.g., currency / tokens), such as fiat currency, for settling bills (i.e., digital receipts) for online and / or real-world goods and / or services provided in both the formal and informal sectors (e.g., housework, home repairs, babysitting, etc.).

[0048] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing an exemplary Star TIP communication signaling protocol that can be configured to enable any service provider, in both the formal and / or informal sectors, to accept Star Currency / Tokens, which can be earned in a variety of ways, including by performing online activities (such as publishing digital content) as disclosed herein, receiving them as tips, and the like, simply by displaying an internet QR code that links directly to a Star Internet Wallet address (such as an MSISDN-B). As detailed herein, at least some embodiments of the present disclosure enable users to digitally receive tips for activities such as physical delivery of goods or services, which may be created through, for example, a so-called digital / virtual Star "tip jar" (Star Internet Wallet, i.e., MSISDN, hashed cellular ID, XYM4, etc.), online marketplaces (FedEx, UPS, Uber Eats, Uber, Lyft, Craig's List, etc.).

[0049] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing the exemplary Star INV (Invoicing) and communication signaling systems, network architectures, and methods disclosed herein to enable any service provider to accept Star Currency / Tokens for instant bill payment capture and / or satisfaction / recording, and to be made to accept and / or record electronic activity (e.g., electronic payments / transactions) on the fly, without the need for a registration process, by simply directing payment to a mobile phone number (e.g., MSISDN, XYM4) encapsulated in a QR code (e.g., URL encoding), in one embodiment. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to address one or more of the technical problems identified herein by utilizing exemplary Star TAP, TIP, and INV protocols that may be configured to use personalized payment URLs (PURLS) and / or QR codes to deliver frictionless, permissive communication sessions based on novel mobile-originated communications that address the signaling and related activities (e.g., payments) disclosed herein. As described in more detail herein, at least some embodiments of the present disclosure may utilize one or more described embodiments to enable peer-to-peer (P2P) communication sessions that may involve the payment and / or transfer of digital tokens (e.g., digital assets representing fiat currency and / or cryptocurrency).

[0050] Exemplary, non-limiting embodiments of cellular systems having elements modified to convert and / or operate cellular communication signals in accordance with a novel cellular communication protocol and network architecture that utilizes a cellular network-hosted access control schema, and methods of using them. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing specially programmed elements of a cellular network, such as control and / or charging elements. In some embodiments, the control routines and charging routines may be programmed to be executed by the same element of the IN. For example, as discussed herein, one technical drawback of a typical IN is that operators / carriers may impose various tariffs, e.g., country-specific international calling tariffs, domestic calling tariffs, on-net / off-net domestic calling tariffs, fixed-line terminated calling tariffs, mobile call termination tariffs, etc., which may themselves be further differentiated by user / customer service contract, profile, or time of day, etc. Additionally, another technical drawback of a typical IN is that calls may be metered without necessarily incurring additional charges, where unlimited calls are offered for a particular class of call in exchange for a fixed subscription fee.

[0051] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein, for example, without limitation, by utilizing one or more elements of a cellular network that can be specially programmed to overcome the technical drawbacks of utilizing a single published tariff for a single class of calls; by allowing multiple charging tariffs to be applied to a single class of calls, for example, by allowing multiple tariffs to be applied to star calls (calls prefixed with a star symbol). In one embodiment, this multiple tariffs is achieved by pre-populating a rating table stored in the non-transitory memory of a specially programmed element (e.g., IN) of a particular cellular network with amounts that directly map and match symbolically prefixed address signals that list and encapsulate the desired charging tariffs. In such an embodiment, a discrete (fixed) number of rating table entries may be populated to define a desired set of tariffs, for example, without limitation, as tabulated and described in FIG. 15B.

[0052] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., an operator's billing system and rating engine) that can be specifically programmed to support the present signaling disclosure, e.g., to computationally and dynamically determine the applicable fee by parsing a symbolically prefixed address signal into integer format equivalent to a monetary appropriate applicable billing rate (e.g., applied to a CDR). For example, converting the address signal string "*NNN" into an "NNN" integer format, e.g., equivalent to a billing rate of NNN cents (¢) to be recorded in a user's mobile phone account data record. In some embodiments, the calculation may include a first step of extracting a fixed number of characters (e.g., three characters in the NNN signaling format) from the address signal string into a substring enumerating the billing rate in order to calculate the appropriate integer value and monetary amount, as described below with reference to FIG. 15B.

[0053] For example, prior to the present disclosure, if a user of a cellular device dialed a keypad, e.g., "*009," the operator would lack the necessary charging intelligence and routing modifications as disclosed herein, and the user would hear an error voice message such as "Call cannot be completed." In contrast, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to take advantage of such network exceptions (errors) by reprogramming the network with new logic to successfully service and support such star calls, thereby enabling microcharging directed by the mobile device, as disclosed herein. Such network error messages can be addressed, without limitation, by, for example, programming one or more elements of the cellular network (e.g., a control element (e.g., SCP / SCF) of the IN, a charging element (e.g., OCS) of the IN) to process the "*009" sequence and recognize (e.g., parse) "009" as a monetary appropriate tariff. and creating or directing the creation of a corresponding CDR in the amount of 9 cents applied to the account associated with the cellular device, and thereafter routing the communication to a service access control platform (e.g., a Star Node or DCB of the present disclosure) to complete the associated Internet transaction.

[0054] In particular, as detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element(s) of the IN (e.g., one or more OCS)) that may be specifically programmed to apply tariffs in a unitary manner rather than pro rata, i.e., a fixed rate rather than a variable rate, as defined by the call tariff, regardless of call duration.

[0055] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein, including, without limitation, by utilizing a HOOK FLASH scheme that intentionally limits calls to a very short duration (e.g., one second), and such fixed rate billing protocols may be achieved by programming to record applicable charges as per minute rather than per second rating charges. Thus, in contrast to the above-detailed technical shortcomings associated with typical PSMS methods, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to be transparent to the user / consumer, as the address signal (e.g., dialed digits) directly equates to the charges to be recorded and billed, creating a one-to-one relationship (i.e., "what you dial is what you pay").

[0056] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., IN control element SCP / SCF and charging element, OCS) that can be specifically programmed to perform micropayment services / charges / payments, including, but not limited to: Limit the maximum transaction amount, Removal of the additional payment verification step Prohibiting recurring subscriptions in favor of supporting SSUs only; · Automatically switch micropayments to elements of the cellular network (e.g., cellular billing systems). As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems of the inability to automatically reverse transactions once submitted, for example, without limitation, by creating a transparent and sustainable process with sufficient transaction details in the records of mobile carriers / operators to reduce or eliminate the burden of charge reversals. Electronic payment processors can address and / or avoid previously unsolvable problems, based at least in part on practical, psychological, and financial grounds. For example, by limiting maximum transaction amounts to small (minor) amounts, the systems and methods disclosed herein eliminate the need to process reversals and refunds because such single-service-unit (i.e., individual) transactions are perceived to be financially insignificant and psychologically insignificant.

[0057] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element(s) of the IN (e.g., one or more OCS)) to enable the cellular network to leverage the cellular telephony network to provide seamless, frictionless, and reliable digital experiences for high-frequency activities, e.g., micro-billing to billions of existing mobile (e.g., cellular) wallets (e.g., digital account records of mobile carriers / entities) holding trillions of dollars of digital airtime currency, for example, related to online digital content and services. For example, as detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), one or more charging elements of the IN (OCS)) can be specially programmed to enable the cellular network to provide micro-commerce functionality (e.g., including, but not limited to, one or more minor denominations of one or more currencies defined by the ISO 4217 standard (e.g., one or more U.S. cents, etc.)).

[0058] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., an SCP / SCF), a billing element(s) of the IN (e.g., one or more OCS)) that can be specially programmed to convert and / or operate cellular signals in accordance with new communication protocols and network architectures to leverage cellular networks (Mobile Telephony Networks) for software licensing, for example, by allowing users to reserve (e.g., purchase) application time, similar to how they currently reserve (e.g., purchase) mobile cellular airtime to rent applications for short periods of time (e.g., a few minutes, an hour, a few hours, a day, a few days, etc.), rather than paying a monthly license fee for infrequent use, and allowing users to precisely control what, when, and how much they consume, rather than being force-fed unwanted digital advertising or being locked into periodic digital subscription additional fees.

[0059] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a controlling element of the IN (e.g., SCP / SCF), a charging element of the IN (e.g., one or more OCS)) that are specially programmed to translate and / or manipulate cellular signals in accordance with new communication protocols and network architectures, enhancing privacy and / or confidence in users' digital online experiences / transactions / interactions that their data is secure and their privacy is protected. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element of the IN (e.g., one or more OCS)) that can be specially programmed to translate and / or manipulate cellular signals in accordance with new communication protocols and network architectures to process transactions of micro-monetary value (minor units of currency) to enable low-cost, highly scalable micropayment activities / transactions / interactions that are switched directly in the dial stream.

[0060] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element of the IN (e.g., one or more OCSs)) that are specially programmed to translate and / or operate on cellular signals in accordance with new communication protocols and network architectures, enabling micro-charging to be performed on short periods (e.g., milliseconds) of mobile-originated signaling emitted during the call setup phase and subject to one or more charging rules that may be defined by switching logic and an Originating Basic Call State Model (OBCSM).

[0061] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element(s) of the IN (e.g., one or more OCS)) that can be specially programmed to translate and / or manipulate cellular signals in accordance with new communications protocols and network architectures such that telephone calls can proceed via a Basic Call State Model (BCSM) using standardized call points (PICS) and trigger detection points (TDPs) and / or initial filter criteria (IFCs), and service trigger points (STPs). The network logic of the present description collectively defines sequential steps that can be applied during initial call setup and ongoing call state management. For example, without limitation, one or more communication protocols detailed herein may utilize the finite state machine functionality of the BCSM and PICS to enable a switching element (e.g., an MSC) configured as detailed herein to interact with one or more control and charging elements of a cellular network (e.g., an Intelligent Network Node according to the ITU-T Q.1200 series recommendations (International Telecommunications Union)), in particular to perform / perform one or more of the authentication, authorization, and / or accounting (AAA) procedures and provide billing verification, real-time account balance management, and call progress monitoring as detailed herein.

[0062] In some embodiments, during one such billing verification step, the requested call may be paused to determine whether the account associated with the caller has sufficient credit to continue and complete the call, i.e., whether the call will proceed to a ringing state, mature, and be answered. Similarly, one or more communication protocols detailed herein may include one or more billing systems that utilize rating engines and / or tables, and Call Data Records (CDRS) that may record transactions and apply charges over digital networks.

[0063] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), one or more charging elements of the IN (e.g., OCS)) that can be specially programmed to translate and / or operate cellular signals in accordance with new communication protocols and network architectures such that the monetary value of a communication, and thus billing, can be quantified by encapsulating discrete charges themselves in the address signals (e.g., digits for decimal numbers) such that the dialed telephony address of a communication enumerates the actual cost of the communication, and consequently the billing charges applied in the operator / administrator / carrier's data records (e.g., databases) associated with the cellular network.

[0064] In some embodiments, one or more novel communication protocols detailed herein are designed to configure / modify / utilize various components of a cellular communication network to enable the monetary value of a communication, and therefore charging, to be quantified by encapsulating the charge itself into a message (e.g., SMS) address signal (e.g., digits for decimal numbers) so that the address of the communication enumerates the actual cost of the communication. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a billing element(s) of the IN (e.g., one or more OCS)) that can be specially programmed to translate and / or manipulate cellular signals according to new communication protocols and uniquely map dialed digits to financially relevant ones, for example, to provide technical transparency to related activities by making the cost of the actual dialed numbers explicit and highlighted (e.g., in a rating table lookup).

[0065] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., an SCP / SCF), a charging element of the IN (e.g., one or more OCSs)) that may be specially programmed to convert and / or operate cellular signals in accordance with novel communication protocols and network architectures to avoid a lack of transparency and traceability on the part of users that may be caused by the ability of third-party platforms to unilaterally withdraw funds from accounts associated with cellular users that would be related to one or more of the technical problems discussed herein. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), one or more charging elements of the IN (e.g., OCS)) that can be specially programmed to translate and / or operate cellular signals in accordance with new communication protocols, such as the mobile (cellular) originated HOOK FLASH signaling protocol disclosed herein, by utilizing an Authentication, Authorization and Accounting (AAA) protocol in mobile (MO) telephony, to transparently enter the charging system of the mobile (cellular) network through the carrier's "front door," so to speak.

[0066] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), one or more charging elements of the IN (e.g., OCS)) that can be specially programmed to translate and / or operate cellular signals according to novel communication protocols and network architectures to uniquely and securely capture the cost of transactions in address signals emitted by cellular devices, and according to one or more disclosed communication protocols such as the HOOK FLASH transaction protocol, inherently and authoritatively generate native cellular charging certificates (CDRs) and irrevocably capture and record transaction data. As detailed herein, at least some embodiments of the present disclosure may utilize one or more elements of a cellular network (e.g., a control element (e.g., SCP / SCF) of an IN, a charging element(s) of an IN,

[0067] The present disclosure is directed to one or more technical solutions designed to address one or more of the technical problems identified herein. The OCS) transparently timestamps all transactions and, for example, can be specially programmed and / or instructed to record transactions that coincide with other telephony calls, displaying dialed addresses along with call duration and listed costs, substantially at the moment of the transaction, and can be directly correlated with the cellular device's call logs (e.g., Recent Calls). For example, transactions managed in accordance with the present disclosure may result in the following cell phone bill entry, as shown in Table 2: [Table 2]

[0068] In some embodiments, the present disclosure considers that a typical credit card transaction is based on two transaction states: 1) Present your card and 2) The card does not exist. For example, card-present typically means that a transaction is considered "card-present" only if electronic data is captured at the time of the transaction, and not just the physical presence of a credit card. Data can be obtained, for example, by swiping a magnetic strip card, dipping an EMV (Europay™, MasterCard™ and Visa™) chip card, or tapping an NFC (near field communication) or contactless digital wallet with a card stored on a smartphone (such as Apple Pay™). For example, a DCB originating from the internet and unable to capture an audit trail of cellular transaction data can be classified as being in a "card not present" transaction state in a typical credit card payment transaction. Typically, even if the customer physically presents the card at the time of the transaction, any payment method will be considered a "card not present" transaction if there is a failure to capture the electronic data when the card is present. Given the system vulnerabilities inherent in card not present transactions, the process becomes more costly at a fundamental level to mitigate fraud.

[0069] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein (e.g., shortcomings of DCB-based services) by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element of the IN (e.g., one or more OCS)) that can be specially programmed to translate and / or manipulate cellular signals in accordance with new communications protocols and network architectures to utilize native and core charging paths applicable to mature cellular telephone calls to respond, for example, by employing the disclosed HOOK FLASH (WINK) protocol, which securely assumes and assumes the presence of an active SIM card and internal data recording. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the current digital payment technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), one or more billing elements of the IN (OCS)) that are specially programmed to translate and / or manipulate cellular signals in accordance with new communication protocols and network architectures to avoid the need for users / consumers to create and manage digital wallets for transactions, avoid the need for carriers / operators to expose internal elements of the carrier's IN (e.g., Core Billing System) to external third parties (e.g., DCB platform providers), and maintain the integrity and / or security of the mobile phone wallet by transacting uniquely and synchronously internally along the mobile phone billing path.

[0070] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein (e.g., shortcomings of DCB-based systems) by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element of the IN (e.g., one or more OCS)) that are specially programmed to translate and / or manipulate cellular signals in accordance with novel communication protocols and network architectures to provide fundamentally more secure and streamlined mobile originated (MO) authentication and transaction actions that do not require manual data entry by the user, and automatically direct payments via elements of the cellular network (e.g., a billing platform) using small payments (e.g., pennies instead of pounds). For example, in accordance with the novel communication protocols and network architectures described herein, in some embodiments, a DCB access control platform of the present disclosure may be programmed in accordance with one or more principles described herein to address and meet mass market adoption and appeal, for example, without limitation: · Limit payments to a maximum micro threshold. · Automatically select and present your mobile phone bill as a single payment method. · Forgoing highly competitive subscriptions for single service units. · Removing additional verification or validation steps.

[0071] Furthermore, in accordance with the novel communication protocols and network architectures described herein, in some embodiments, a DCB access platform (e.g., the STARKEY platform) of the present disclosure may be programmed to operate according to one or more principles described herein to facilitate payments beyond gambling and gaming to a broader market in mass content publishing and consumption. In some embodiments, limiting payments to minute amounts may also circumvent regulatory spending limits and requirements, as transactions may now be limited to the realm of pocket change. Furthermore, by avoiding the vulnerabilities and friction introduced by 2FA and multi-stage PSMS verification, a DCB platform reprogrammed according to one or more principles of the present disclosure may provide a ubiquitous and highly streamlined payment process not previously achievable. For example, without limitation, as further detailed herein, in some embodiments, a DCB platform reprogrammed according to one or more principles of the present disclosure may operate based on the following reduced instruction set and simple sequence of events, processed within a single digital payment and interface channel (e.g., STAR BAND): The user taps a cellular micropayment button that displays the purchase amount for the associated restricted-access content / service. The cellular network (e.g., IN) determines the cellular device identity of the cellular device. The DCB platform charges the account associated with the identified cellular device; and · Users have instant access to products and services. Additionally, in some embodiments, if the MPBN is not an active data bearer, resulting in the cellular network being unable to internally identify the cellular device, the IAPP may, for example, automatically activate a random challenge system / engine to allow any network to seamlessly and securely identify the cellular device. For example, in at least some embodiments, the cellular device may have previously been identified and an identity (e.g., MSISDN) or a unique derived identity (e.g., cryptographically hashed MSISDN) communicated to the IAPP.

[0072] In some embodiments, the exemplary inventive computer-based systems / platforms, exemplary inventive computer-based devices, and / or exemplary inventive computer-based components of the present disclosure may utilize encryption technologies (e.g., private / public key pairs, Triple Data Encryption Standard (3DES), block cipher algorithms (IDEA, RC2, RC5, CAST, Skipjack, etc.), cryptographic hash algorithms (MD5, RIPEMD-160, RTR0, SHA-1, SHA-2, Tiger (TTH), WHIRLPOOL, RNG, etc.). As detailed herein, at least some embodiments of the present disclosure utilize a trusted network (e.g., a cellular network, IN) and a secure communications coupling of an access control component of the *O / S (e.g., the STARKEY Platform) that is programmed to recognize the identity of the cellular service-enabled device (e.g., a mobile phone) used by a user to dial and / or send an SMS with a randomized address signal, corresponding to mobile origination rather than a mobile terminating code. As detailed herein, at least some embodiments of the present disclosure utilize a secure communications coupling of an access control component of the *O / S (e.g., the STARKEY Platform) that hashes the detected MSISDN (XMISDN), concatenates and hashes the detected MSISDN to a secret master key (XYMSISDN), and converts the resulting hash into, for example, but not limited to, the last N digits of the plaintext MSISDN (e.g., XM4, XYM4) that may deliver a human-readable / recognizable hash without compromising security. As described in more detail herein, in at least some embodiments of the present disclosure, an access control component of the *O / S (e.g., the STARKEY platform) may be configured to purge (e.g., not store or persist) the detected MSISDN after computing the MSISDN hash. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein (e.g., shortcomings of DCB-based services) by utilizing one or more elements of a cellular network (e.g., a controlling element of the IN (e.g., an SCP / SCF), a charging element(s) of the IN (e.g., one or more OCS)) that can be specially programmed to convert and / or manipulate cellular signals in accordance with new communication protocols and network architectures to enable streamlined secure access action sequences (including micro-billing) that can be initiated, performed, and completed based on just one step (e.g., one tap of a button) by the user / consumer, for example, as illustrated, without limitation, in FIG. 13B , by establishing a single activity channel (e.g., a single transaction channel (STAR ​​BAND)) that connects the online environment with element(s) of the cellular network (e.g., the IN), without requiring additional steps and without requiring manual data entry by the user / consumer. By establishing a single activity channel (e.g., a single transaction channel (STAR ​​BAND)) with an element of the cellular network (e.g., an IN), by establishing a single activity channel (e.g., a single transaction channel (STAR ​​BAND)) with an element of the cellular network (e.g., an IN),

[0073] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by leveraging one or more elements of a cellular network (e.g., an IN's control element (e.g., SCP / SCF), an IN's charging element (e.g., one or more OCS)) to leverage existing digital cellular wallets (e.g., prepaid cellular accounts, prepaid SIM cards, non-prepaid cellular accounts with credit allowances, etc.) and currency in the hands of billions of people accessible via telephony address signals (e.g., telephony numbers). While such mobile phone-linked digital wallets and their associated currency, billing, and payment arrangements are limited to control the amount of network time and / or data each user / consumer is allowed to consume, in accordance with novel communication protocols and network architectures, at least some embodiments of the present disclosure uniquely utilize, based at least in part on address signals, the cellular network's linked currency, billing, and payment arrangements to support a single action access channel linking Internet-based and / or virtual-based and / or physical environments with the cellular network's communication environment to seamlessly utilize the cellular network's linked currency, billing, and payment arrangements for access to and / or consumption of a variety of products and / or services, including, but not limited to, virtual products (e.g., Internet-hosted content), virtual services (e.g., Internet-hosted services), physical products, physical services, or any combination thereof.

[0074] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more elements of a cellular network (e.g., the need for the creation (and management) of digital wallets, a typical obstacle to mass adoption of online micro-commerce); a control element of an IN (e.g., SCP / SCF, charging element of an IN (e.g., OCS)), which may be specially programmed to translate and / or operate cellular signals according to new communication protocols and network architectures to enable seamless online transactions using existing digital cellular wallets. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of an IN (e.g., SCP / SCF), charging element of an IN (e.g., one or more OCSs), which may be specially programmed to translate and / or operate cellular signals according to new communication protocols and network architectures to enable, but are not limited to, the following: · Rebuild and repurpose cellular networks with payments made in a single call that takes less than a second. Leverage scalable cellular networks and related elements to enable instant / real-time micro-billing. · Providing a new way to utilize existing cellular digital wallets that work for billions of cellular users. Influence the movement of mobile currency across the ring, cloud, and internet, in milliseconds, with marginal signaling costs, and only for uniquely anticipated transactions; and · Provide a seamless, frictionless, and satisfying user experience based on a single-action access channel.

[0075] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein (e.g., shortcomings of DCB-based systems) by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., an SCP / SCF), one or more charging elements of the IN (e.g., one or more OCS)) that can be specially programmed to translate and / or manipulate cellular signals in accordance with new communication protocols and network architectures to perform various processes disclosed herein without external charging exposure to the cellular network carrier / operator, without requiring disclosure of additional financial instruments by users, and without requiring users to participate in the utilization and / or management of security elements (e.g., forms of encryption keys, transaction PIN codes, usernames, passwords, etc.).

[0076] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein (e.g., shortcomings of DCB-based systems) by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., an SCP / SCF), a charging element of the IN (e.g., one or more OCS)) that may be specially programmed to convert and / or manipulate cellular signals in accordance with new communication protocols and network architectures to utilize unlimited prepaid billing in the form of airtime vouchers of various denominations that a user / consumer acquires at a retail store or online and loads into a mobile phone wallet (account). In some embodiments, the prepaid cellular account may function as a fiat-backed digital currency. For example, a user may also be permitted to send (gift) airtime directly from one wallet to another using the provided cellular network services. For example, without limitation, as a user / consumer consumes cellular network time and / or resources, the balance of a prepaid account associated with the corresponding cellular device is depleted. In some embodiments, when the prepaid balance reaches zero, cellular network service may be suspended until such time as the user / customer replenishes their account.

[0077] Postpaid users are typically credit-worthy customers who typically settle their cellular network accounts at the end of a billing cycle (e.g., monthly). That is, prepaid customers pay before consumption (PRE), while postpaid customers pay after consuming cellular network resources or services (POST). Prepaid billing is typically performed substantially in real time for communications, while postpaid billing is typically billed in cycles. As detailed herein, in at least some embodiments, one or more technical solutions of the present disclosure are designed to utilize prepaid, postpaid, hybrid, and blended cellular billing models.

[0078] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element of the IN (e.g., one or more OCS)) that are specially programmed to convert and / or operate cellular signals in accordance with novel communication protocols and network architectures, and without limitation to utilize marginal network signaling during call origination setup, so that the cost for establishing a single-action access channel with the cellular network environment may be infinitesimally fixed, allowing switching of very low denominations / minor units (e.g., pennies), such that the technical solutions of the present disclosure may be simple (e.g., a single click by a user), low cost (e.g., less than 99 cents), secure (e.g., less vulnerable than PSMS over SS7 communications), fast (e.g., 1 second), and scalable (e.g., serving billions of instant users / consumers). As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element of the IN (e.g., one or more OCS)) that can be specially programmed to convert and / or manipulate cellular signals in accordance with new communication protocols and network architectures to enable more in-depth pay-per-view (PPV), single service unit (SSU) digital content charging models in which a user / consumer pays only for at least one individual access and / or consumption of a product (e.g., digital content, physical product) or service (digital service, service at a physical facility, etc.). For example, rather than paying a recurring subscription fee, one can pay for a single article, photo, song, video, or other creative work of art or digital service.

[0079] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element of the IN (e.g., one or more OCS)) that can be specially programmed to translate and / or manipulate cellular signals in accordance with new communication protocols and network architectures to enable mobile network operators (MNOs) of cellular networks to pivot their legacy and analog telephone networks into transaction platforms utilizing a single access channel to the online and / or physical environment. Utilization of marginal network signaling. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a charging element of the IN (e.g., one or more OCS)) that can be specially programmed to convert and / or operate cellular signals in accordance with novel communication protocols and network architectures to enable reduced call holding times (CHT) to as little as one second and increased busy hour call attempts (BHCA), based at least in part on various HOOK FLASH signaling protocols described herein, thereby increasing the density of calls that the network can sustain during peak hours.

[0080] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., an IN's control element (e.g., SCP / SCF), an IN's charging element (e.g., one or more OCS)) to leverage (e.g., reprogram) existing legacy cellular networks to address the commonly recognized lack of technically successful micro-access control platforms by utilizing modern digital mobile phones and the subscriber identity modules (SIMs) that uniquely identify them, which can be specially programmed to translate and / or manipulate cellular signals in accordance with new communication protocols and network architectures, but are essentially wireless "credit / debit cards."

[0081] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a control element of the IN (e.g., an SCP / SCF), a charging element(s) of the IN (e.g., one or more OCSs)) that may be specially programmed to translate and / or manipulate cellular signals in accordance with new communication protocols and network architectures to enable a user / consumer to dial a transaction amount from their mobile phone and digitally sign the transaction with a symbol character (e.g., the “*” key), thereby authorizing the payment. Furthermore, at least some embodiments of the present disclosure operate through a single access control channel that logically links and synchronizes the cellular signaling channel with the Internet data channel (i.e., inline within the browser program or APP where items for purchase are presented and consumed), and transactions may be described as occurring out-of-band or above-band, or more appropriately, in preferred signaling embodiments, in the STAR BAND.

[0082] Exemplary terms utilized in at least some embodiments described herein: Table 3 provides a complete explanation of abbreviations that may appear in this disclosure. [Table 3-1] [Table 3-2] [Table 3-3] [Table 3-4] [Table 3-5] [Table 3-6] [Table 3-7] [Table 3-8] [Table 3-9]

[0083] In at least some embodiments described herein, the terms “mobile,” “cellular,” “cellular,” and “telephone” are used interchangeably to describe modern GSM / TDMA / CDMA / UMTS / IP digital wireless telephony and communication networks. While illustrations may depict smartphones, any telephone is applicable, including basic feature phones, IP phones, and VOIP phones. References such as “mobile device” may be interchangeable with “user of the mobile device.” In at least some embodiments described herein, network elements may be referred to in the singular but may incorporate elements in the plural. In at least some embodiments described herein, network subsystems (e.g., billing systems) may incorporate elements from other subsystems (e.g., IN control systems).

[0084] In at least some embodiments described herein, "communication signal," "communication signal," "mobile communication signal," "mobile communication signal," "cellular communication signal," "cellular communication signal," "cellular communication signal," etc. are used interchangeably and may partially or fully encode digital signals, data, and / or digital data packet(s), including, for example, but not limited to, (1) cellular transmission utilizing radio frequencies and associated element / device(s) programmed to operate according to one or more appropriate cellular transmission protocols, (2) transmission according to one or more wireless internet-related protocols and corresponding programmed device / element(s), or (3) any combination of any embodiment of (1) and any embodiment of (2). In at least some embodiments described herein, the term "element(s)" or the like may describe a programmed computing device(s) that partially or fully executes at least a portion of a software program that resides in one or more non-transitory computer memory blocks (e.g., without limitation, flash memory, RAM, ROM, etc.), software program(s), or a combination thereof. In at least some embodiments described herein, terms such as "cellular network," "mobile network," "cellular telephony network," "mobile telephony network," "cellular mobile network(s)," "cellular communications network," etc. are used interchangeably.

[0085] In at least some embodiments described herein, terms such as "micro," "micropayment," "microtransaction," "microaction," "microactivity," etc., refer to one or more minor units of one or more currencies (e.g., one or more U.S. cents, etc.) as defined, for example, by the ISO 4217 standard published by the International Organization for Standardization. In at least some embodiments described herein, for example, a micropayment describes a small quantum transaction in minor units of one or more currencies (e.g., typically less than $1) as defined by the ISO 4217 standard, but one or more of the principles / protocols / methods / systems / devices / platforms described herein may be programmed / utilized for activities / actions / transactions exceeding that amount. For example, transactions of $10 or more may be equally applicable. In some embodiments, one or more of the principles / protocols / methods / systems / devices / platforms described herein may be programmed / utilized for activities / actions / transactions typically settled using other banking instruments, such as debit and / or credit cards. In at least some embodiments, the letter "Y" in conjunction with other Y characters represents a telephony decimal digit (0-9), or collectively an entire telephony number. The sequence +Y YYY YYYY can represent a typical e164 format MSISDN (e.g., 11 digits, including + as the outgoing international dialing symbol), unless otherwise specified. The MSISDN may be transmitted and displayed as the calling line ID (CLI).

[0086] In at least some embodiments, the letter "X" herein may represent a decimal address signal (e.g., digits 0-9). In some embodiments, the letters "X" and / or "Y" may represent randomly generated decimal numbers. In at least some embodiments, the term "caller" is interchangeable with "A" party. Party is interchangeable with associated telephony device (phone). Embodiments may display callers as "A," "B," "C," etc. to distinguish between different callers. In at least some embodiments, the letters "A" and "B" (etc.) represent the cellular MSISDN A and B, or cryptographically hashed cellular IDs (XYM4-A, XYM4-B). The enclosed square brackets "[ ]" represent a digital money wallet (e.g. Star Wallet). The notations "[A]" and "[B]" represent CELL wallets A and B (e.g., prepaid accounts associated with prepaid SIM cards, postpaid accounts with mobile phone service carriers, etc.). In at least some embodiments, the notation "[*A]" and "[*B]" represent STAR Internet Wallets A and B, i.e., wallets created and maintained by the systems and methods disclosed herein (e.g., wallets associated with a Cellular ID and the exemplary STAR Platform of the present disclosure).

[0087] In at least some embodiments, and throughout this disclosure, a cellular identity, e.g., MSISDN, may be interchangeable with a cryptographically derived and / or expanded identity, e.g., C24XYM per the hashing methods disclosed herein. In at least some embodiments, the NNN notation may signal a MICRO BAND data structure or a MACRO BAND data structure. In at least some embodiments, the term MICRO herein may describe a data structure configured to represent payment units typically between $0.01 and $1.00. In at least some embodiments, the term MICRO herein may be extended, for example, without limitation, to an upper limit of $9.99 supported by a fixed three-digit number notation (NNN). In at least some embodiments, the term MACRO herein may describe a data structure configured to encode variable lengths and / or consequently variable ranges of units and payments / amounts, typically exceeding a MICRO, in one embodiment from $1 to $1000 and above. In at least some embodiments, all star dialing numbers may include more digits than the STAR P2P protocol specifies (e.g., more than three digits in NNN embodiments), and the signal (e.g., *NNNXXX, *NNN*XXX) may be parsed by elements of the cellular network, such as an admission control scheme (e.g., a cellular system's charging and / or OCS (Online Charging System)), to extract the first NNN of the microband signaling digits from the star address, for example, to determine the mobile phone tariff / toll / fee / charge for applying for a switching transaction. In some embodiments, the present disclosure may describe a prepaid cellular account whose currency unit is network airtime backed by fiat currency, and an accounting test that may determine whether the account has a sufficient credit balance to maintain charges. It is understood that the various technical solutions of the present disclosure are equally applicable to postpaid accounts, where the accounting test may determine whether the user has credit sufficiency (i.e., creditworthiness) to maintain the obligations incurred by pending transactions.

[0088] Thus, some embodiments may describe deducting the amount from a mobile phone account, but may equally describe debiting (posting) the amount to an account for later settlement. While debit and deduction may technically describe different bookkeeping principles, they are applied here in the broader context of having sufficient credit in an account associated with usage to maintain charges, rather than the narrow context of having a sufficient (prepaid) credit balance in an account. Thus, the two terms can be used interchangeably.

[0089] Payment quanta can be expressed in dollars, decimals, or unitary (¢) notation. While examples herein may show dollar ($) amounts, any currency (e.g., currencies defined by the ISO 4217 standard) may similarly be mapped to dialed digits as disclosed. In some embodiments, dollar amounts may be displayed as flat sticker prices and then converted to local currency at the time of the transaction. In some embodiments, dialed digits and corresponding monetary equivalents are localized to the local currency by referencing the MSISDN of the cellular device utilized to effect the payment. STAR Wallet's digital store, referred to herein as STAR CURRENCY, is a highly fungible, fiat-backed token.

[0090] In some embodiments, the term IP Endpoint (IPE) herein refers to a discrete piece of digital content or service, a Document Object Model (DOM) element in a browser page (e.g., without limitation, presented via XML or HTML), a user interface element on an Internet-connected device, an application, an application terminal, a web page, etc. In some embodiments, an IPE may be addressable via a unique Internet address, including, without limitation, a socket address, a port number, etc., bound to the digitally identifiable element. In some embodiments, the address signal of a cellular call may be symbolically prefixed with a star (*), double star (**), hash (#), double hash (##), star hash (*#), hash star (#*), or other symbol or combination of symbols. In some embodiments, such a symbolic prefix shifts the address signal one position to the right, escaping the normal dialing address domain into a previously unused (e.g., star) number area. In some embodiments, without limitation, a Mobile Switching Center (MSC) is referred to as the transaction node responsible for generating cellular micro-charging tickets (records). Typically, the MSC is the switching element and function in traditional 2G / 3G circuit-switched telephony networks. In more modern 4G / 5G packet-switched telephony networks, such as networks utilizing the Internet Multimedia Subsystem (IMS) architecture or networks utilizing Voice over Long Term Evolution (VoLTE), other network nodes and elements may be responsible for generating these transaction records, including, but not limited to, a Serving Call Session Control Function (S-CSCF) and / or a Telephony Application Server (TAS).

[0091] In some embodiments, whether a circuit, packet, or hybrid circuit and packet switched network architecture is utilized, an associated online charging system (OCS) typically manages user account balances and makes charging decisions. The OCS may consist of a session balance control function (SBCF), an account balance management function (ABMF), and a rating function (RF) to determine charges (i.e., fees) for communications. For approximately 150 years since the first telephony call, rings have only transmitted calling line ID (CLI). In some embodiments, the technical solutions of the present disclosure teach how to conduct currency over telephony rings. In some embodiments, "RING COMMERCE," "RING TRANSACTION(S)," and the like are terms coined herein to describe transactions over the ring, thereby literally ringing up sales in online and / or non-online environments. STAR(*) is a universal key in the cellular matrix (telephony dial pad). In some embodiments, elements of a cellular network may be programmed to recognize STAR("*") as a symbolic network routing prefix, a name given to cellular network signaling and switching elements (nodes) that service and control the micropayments disclosed herein in accordance with at least some novel communications protocols and architectures. In some embodiments, while the disclosed STAR NODE is depicted as a SIP signaling server, other signaling systems, protocols (e.g., without limitation, SS7 and ISUP) and / or entities may be utilized to achieve the same transaction result (e.g., microtransactions over a distinctive access channel (interchangeably referred to herein as the STAR BAND)).

[0092] In some embodiments, the term "server" should be understood to refer to a service point that provides processing, database, and communication facilities. By way of example and not limitation, the term "server" can refer to a single physical processor with associated communication and data storage and database facilities, or a network or clustered complex of processors and associated network and storage devices, as well as operating software and one or more database systems and application software that support the services provided by the server (e.g., a cloud server). In some embodiments, the terms "cloud," "Internet cloud," "cloud computing," "cloud architecture," and similar terms correspond to at least one of the following: (1) a large number of computers connected via a real-time communication network (e.g., the Internet); (2) a large number of computers connected via a real-time communication network (e.g., the Internet); (3) a large number of computers connected via a real-time communication network (e.g., the Internet); (4) a large number of computers connected via a real-time communication network (e.g., the Internet); (5) a large number of computers connected via a real-time communication network (e.g., the Internet); (6) a large number of computers connected via a real-time communication network (e.g., the Internet); (7) a large number of computers connected via a real-time communication network (e.g., the Internet); (8) a large number of computers connected via a real-time communication network (e.g., the Internet); (9) a large number of computers connected via a real-time communication network (e.g., the Internet); (10) a large number of computers connected via a real-time communication network (e.g., the Internet); (11) a large number of computers connected via a real-time communication network (e.g., the Internet); (12) a large number of computers connected via a real-time communication network (e.g., the Internet); (13) a large number of computers connected via a real-time communication network (e.g., the Internet); (14) a large number of computers connected via a real-time communication network (e.g., the Internet); (15) a large number of computers connected via a real-time communication network (e.g., the Internet); (16) a large number of computers connected via a real-time communication network (e.g., the Internet); (17) a large number of computers connected via a real-time communication network (e.g., the Internet); (18) a large number of computers connected via a real-time communication network (e.g., the Internet); (19) a large number of computers connected via a real-time communication network (e A network-based service that appears to be provided by real server hardware, but is actually provided by virtual hardware (e.g., virtual servers) simulated by software running on one or more real machines (e.g., that can be moved and scaled up / down on the fly without impacting service to end users). Of course, the above examples are illustrative and not limiting.

[0093] In some embodiments, according to the technical solutions of the present disclosure, a user (and / or an associated cellular device) simply dials an asterisk (*) symbol followed by digits that correspond to a monetary amount, as taught herein. In some embodiments, according to the technical solutions of the present disclosure, an access (event) activity (e.g., a micropayment transaction) can typically be completed in as little as one second or less. In some embodiments, according to the technical solutions of the present disclosure, an access (event) activity (e.g., a micropayment transaction) can typically be completed in as little as two seconds or less. In some embodiments, according to the technical solutions of the present disclosure, an access (event) activity (e.g., a micropayment transaction) can typically be completed in as little as three seconds or less. In some embodiments, according to the technical solutions of the present disclosure, an access (event) activity (e.g., a micropayment transaction) can typically be completed in as little as four seconds or less. In some embodiments, according to the technical solutions of the present disclosure, an access (event) activity (e.g., a micropayment transaction) can typically be completed in as little as five seconds or less. In some embodiments, according to the technical solutions of the present disclosure, a user's cellular device generates an authenticated (signed) cellular signal (e.g., an address signal) listing monetary amounts that can be processed by: Presentation of ringback tones, followed by · Call connection and disconnection (e.g. HOOK FLASH / WINK protocols). In some embodiments, by momentarily connecting and then disconnecting a call, the technical solutions of the present disclosure uniquely utilize signaling techniques, such as, without limitation, a "hook blink" or "wink" as disclosed herein, to instantly switch and effectuate microtransactions on a device (such as a smartphone) by generating an event record (e.g., a billing ticket at the originating switching element (MSC or appropriate IMS charging node)) in an account associated with the corresponding mobile phone and tracked in the associated mobile carrier / carrier database. In some embodiments, one or more technical solutions of the present disclosure may be referred to as "flash commerce." In some embodiments, in accordance with the technical solutions of the present disclosure, the resulting event record (e.g., a mobile phone billing ticket, also referred to herein as a CDR (Call Data Record)) includes a star signaling event, which may be utilized to debit (or subtract) the appropriate monetary amount of the dialed digits from an account associated with the caller device (caller account). In some embodiments, according to the technical solutions of the present disclosure, a resulting event record (e.g., a mobile phone charging ticket (billable CDR)) may be generated when a call lasts for 1 second. In some embodiments, according to the technical solutions of the present disclosure, a resulting event record (e.g., a mobile phone charging ticket (billable CDR)) may be generated when a call lasts for at least 500 milliseconds. In some embodiments, according to the technical solutions of the present disclosure, a resulting event record (e.g., a mobile phone charging ticket (billable CDR)) may be generated when a call lasts for at least 100 milliseconds. In some embodiments, according to the technical solutions of the present disclosure, a resulting event record (e.g., a mobile phone charging ticket (billable CDR)) may be generated when a call lasts for at least 50 milliseconds. In some embodiments, according to the technical solutions of the present disclosure, a resulting event record (e.g., a mobile phone charging ticket (billable CDR)) may be generated when a call lasts for at least 1 millisecond. [Figure 1] 1 illustrates a remote control access schema system and method in accordance with one or more embodiments of the present disclosure. An exemplary computing device (Internet-connected device) 100 running an Internet application program (IAPP) 101 requests an Internet resource (e.g., a web page) via an application programming interface (API) 102 that connects to a remote server 111, which in one embodiment is hosted on a cloud 110. The remote server 111 returns at least one application program instruction (as represented by the generic script notation "") to the IAPP 101, which renders and displays an access controller interface element 103 with an exemplary access code NNN displayed, and in one embodiment, a linked URL 131 that references an access-restricted digital resource (130) (e.g., Internet-hosted content) and / or an access-restricted service 132.

[0094] In one embodiment, the API may transfer multiple pieces of data, such as an access code NNN, a URL 131 referencing Internet content or service 132, a parameter identifying the cellular device (e.g., MSISDN) for a previously identified cellular device, and any other access control metadata. The cellular ID may be associated with the Internet-connected device 100 or any other previously identified cellular device. Upon receiving a request for an Internet resource, the remote server 111 responds to the IAPP 101 with at least one application program instruction 102 (again, as depicted by the generic script notation “”) for rendering an access controller interface element 103. The at least one application program instruction 102 may include, without limitation, code for stylizing the access controller interface elements 103 (e.g., HTML markup and / or CSS) and the displayed access code (NNN). In addition to providing script(s) for stylizing the interface elements 103, the at least one application program instruction may include service logic (e.g., JavaScript) that executes when the interface elements are activated. In one embodiment, the at least one application program instruction may, without limitation, thus encode button rendering scripts (e.g., using HTML, CSS, or any combination thereof) for stylizing the interface elements 103 and the presented display access code (NNN), and further provide control schema 121 that communicatively couples the interface elements 103 to the cellular network 120.

[0095] In an embodiment, at least one application program instruction communicatively coupling the access controller interface element 103 to the cellular network control schema 121 may instruct the activation and / or initiation of a mobile-originated cellular communication protocol to transmit / originate an access request including a symbolically prefixed address signal (e.g., *NNN as disclosed herein) related to the detection of at least one activity associated with the access controller interface element 103. In some embodiments, the at least one activity associated with the access controller interface element 103 may be an activation of the access controller interface element 103 when a user of the computing device 100 clicks / selects the access controller interface element 103 and / or when a user of the computing device 100, while scrolling through the online content, advances to a portion of the online content that displays the access controller interface element 103. The activation of the access controller interface element 103 may be operatively linked to an access-restricted digital resource (e.g., the access controller interface element 103 is in a focused state on the screen of the computing device 100). The mobile-originated communication protocol may be, but is not limited to, a telephony call setup request, a short message service (SMS) request, or an unstructured supplementary service data (USSD) request. In some embodiments, upon detecting at least one activity with the access controller interface element 103 (e.g., activation of the access controller interface element 103), access request data may thus be communicated along the cellular signaling path 105 to the cellular network-hosted access control schema 121, which may in turn communicate at least one access program instruction.via a remote internet access control server 111 (e.g., in one embodiment, addressed over a translated symbolic network routing prefix as described in Figure 15 below), and back to the access controller interface element 103 using an API 104.

[0096] In some embodiments, client-server interaction as described between an Internet client device 100 (running IAPP 101) and a remote Internet access control server 111 may occur along an established Internet communication path (e.g., API schema 104 represented by the generic HTTP “ / / ” communication protocol). While this communication path may be utilized in this disclosed schema (e.g., in modified DCB embodiments as newly disclosed herein), one technical solution in the disclosed remotely programmed access schema is that, in one embodiment, the remote Internet access control server (111) may inject new programming logic into the IAPP (101) running on the client device (100). This redefines and pivots client-server communication from one typically conducted over the Internet, e.g., using HTTP GET / PUT or JSON data exchange protocols along Internet communication path 104, to one transported over a cellular network 120 using a Mobile Originated (MO) signaling protocol along cellular communication path 105. By communicating in this manner, data is securely transferred over cellular rather than Internet channels, from outside the Internet band or even above (e.g., within) the STAR BAND, as disclosed and described in detail herein.

[0097] Thus, when the Internet-connected device 100 detects that the access control interface element 103 has been activated (e.g., when a user taps / clicks on the interface element), service logic programmed and provided by the remote Internet access control server 111 is executed. In one embodiment, this service logic may be configured to utilize Internet APIs to transfer access control data over the Internet communication channel 104 (e.g., " / / " as indicated by "HTTPS: / / "), including but not limited to transferring an access code (NNN) and a cellular device ID (e.g., MSISDN) to the remote Internet access control server 111. In one embodiment, the service logic may transfer the access control data over the cellular communication channel 105 using a mobile-originated signal directed to the network access control schema 121, which may then communicate access control instructions to the remote Internet access control server 111, as described above. In an embodiment, upon receiving the access control data via Internet communication channel 104, remote Internet access control server 111 then transmits the communicated data (e.g., access code NNN and cellular device ID, access code NNN and cellular device ID, access code, access code, access code, access, e.g., MSISDN, etc.) to cellular network access control element 121 via cellular communication path 105, bypassing remote Internet access control server 111, as described above.

[0098] In one embodiment, the newly configured cellular network-hosted access control schema 121 recognizes and interprets the displayed access code NNN (e.g., URL 131) to list the fee ($N.NN) to be applied to the account associated with the identified cellular device (e.g., MSISDN) to grant access to the referenced content or service 132 (e.g., MSISDN). In one non-limiting embodiment, the access controller interface element 103 is rendered by the IAPP 101 as a graphical user interface element (e.g., a transaction submit button) that displays the access code NNN, formatted in one embodiment as a purchase price (e.g., $N.NN or NNN¢ as disclosed herein) payable for access to the Internet content or service 132. The graphical user interface element 103 may be defined by at least one application program instruction 102 received from the remote Internet access control server 111 as described above, and thus presented as a uniformly designed payment button (e.g., shape, size, and color) appropriately branded and thus instantly recognizable as a mobile phone billing payment method. It also displays the transaction amount ($N.NN or NNN¢) as disclosed herein for accessing the linked Internet content or service (132). Presenting a consistently branded, stylized, and therefore instantly recognizable payment method (e.g., interface element) is essential to engender trust and mass market adoption for mobile phone billing as disclosed herein.

[0099] In one embodiment, the cellular network control schema is therefore a cellular charging and billing schema (e.g., OCS) configured to determine whether an account associated with an identified cellular device (e.g., MSISDN) has sufficient credit necessary to maintain a charge $N.NN listed by access code NNN, as described herein with reference to Figures 15A and 15B below. Upon determining that the cellular account associated with the provided cellular ID (e.g., MSISDN) has sufficient credit to maintain the $N.NN charge, as enumerated by the access code NNN, the cellular network-hosted access control schema 121 may communicate the successful transaction to the remote server 111, which may then instruct the access controller interface element 103 to grant access to the linked content 132, as referenced by the URL 131, via the Internet communication channel (API) 104. Upon receiving the instruction to grant access, the access controller interface element 103 displayed in the IAPP 101 instructs the Internet-connected device 100 to access (search for) and present the linked content or service 132. In at least some embodiments, the access-restricted digital resource (130) may be an IAPP 101 with no conflicting registration (a valid authenticated ID (e.g., MSISDN)). [Figure 2] Figure 2 depicts another example of a payment network architecture for implementing a process based at least in part on the mobile communication signals of Figure 20 below, in accordance with at least some embodiments of the present disclosure. Figure 2 includes an example of a digital content payment lifecycle and access via the payment network architecture. In some embodiments, the access control platform 210 hosts access-restricted digital services and / or content under a virtual lock 211. In some embodiments, the internet service may request the access control button 213 via a suitable communication, messaging, and / or interface protocol. For example, in some embodiments, the internet service may send a request to the access control platform 210, e.g., utilizing an application programming interface (API), and the access control platform 210 may respond with the same or a different API to return interface elements. The interface elements may include the access control button 213 and / or any other suitable interface elements. In some embodiments, the term "application programming interface" or "API" refers to a computing interface that defines the interaction between two or more software intermediaries. An API defines the types of calls or requests that can be made, how the calls can be made, data formats that must be used, rules that must be followed, and other requirements and constraints. APIs can be completely custom, specific to a component, or designed based on industry standards to ensure interoperability, enable modular programming through information hiding, and allow users to use the interface independently of the implementation.

[0100] In some embodiments, a user may navigate to content on an Internet service using Internet device 212. In some embodiments, Internet device 212 may include any suitable software and / or application for navigating to content, such as a web browser, an Internet-connected application, an Internet messaging application, a media streaming service, a Real Simple Syndication (RSS) feed, or any other suitable Internet-accessible content access and / or distribution software, or any combination thereof. In some embodiments, upon navigating to content, the internet service may deliver to the internet device 212 a content access interface that presents the content and interface elements that include an access control button 213. In some embodiments, the content may be presented as a user-selectable content interface element that identifies the content. For example, the content interface element may include, for example, a thumbnail, a hyperlink, a list item, an icon, or other text and / or image representative of the content. In some embodiments, the access control button 213 may be presented in association with the content interface element to indicate that the access control button 213 is selectable for the content. For example, the access control button 213 may be rendered, for example, as an overlay on the content interface element adjacent to the content interface element, on a list row adjacent to the content interface element, with a leading line pointing to the content interface element, or via any other design feature or any suitable combination thereof. In some embodiments, a user may generate an access request to access content via internet device 212 by selecting access control button 213, a content interface element, or both. In some embodiments, the access request may include a communication staging a transaction event in the access control ledger. In some embodiments, the transaction event may be for a value associated with access to content and an anticipated telephony device 221. In some embodiments, the anticipated telephony device 221 may include an appropriate telephony device 221 registered in the access control ledger for the particular content and / or particular internet service associated with the value of the transaction event. In some embodiments, the telephony device 221 may be registered by, for example, pairing, designating, linking, or otherwise associating a unique identifier associated with the telephony device 221 to the transaction event. In some embodiments, the unique identifier may include, for example, the MSISDN, a cryptographically hashed MSISDN, or an extended hashed MSISDN of the telephony device 221.

[0101] In some embodiments, the access control button 213 may represent a request to a user viewing the content on the internet device 212 to pay for access by activating (e.g., touching or otherwise selecting via an appropriate input device) the access control button 213. Thus, the access control button 213 may display a value (price) for accessing the content. In the example depicted in FIG. 2, the user is therefore requested to pay 10¢ to access the service or content, as indicated by the price presented on the access control button 213. In some embodiments, to satisfy a request to pay for access to content, a user may initiate a transaction using a telephony call from telephony device 221 using address signals including a symbolic prefix followed by digits formatted to recite the requested price. A specially configured IN 220 may utilize the address signals to route the telephony call and execute the transaction based on the symbolic prefix followed by digits. In the example depicted in FIG. 2, a user may utilize IN 220 to dial *10 from telephony device 221 presented in portrait mode, as described in more detail below. In some embodiments, the internet device 212 and the telephony device 221 are one and the same device. Thus, tapping the button to activate the access control button 213 can control the mobile device 212 / 221 to open a native telephony dialer pre-addressed with a symbolic prefix followed by digits listing the appropriate amount of the price as a telephone number. For example, the access control button 213 can include software instructions configured to instruct the mobile device 212 / 221 to open a native telephony dialer pre-addressed with the price of the content, e.g., *10 for 10 cents.

[0102] In some embodiments, the internet device 212 and the telephony device 221 are separate devices. Thus, a user can read the price and manually enter the digits listing the price after the symbolic prefix into the dialer. In some embodiments, communication between the internet device 212 and the telephony device 221 may enable the internet device 212 to automatically control the telephony device 221 to open a native telephony dialer pre-addressed with the symbolic prefix, preceded by digits listing the monetary value of the price as a telephone number. For example, the access control button 213 may include software instructions configured to instruct the internet device 212 to broadcast a radio signal to the telephony device 221. The radio signal may include instructions to the telephony device 221 to open a native telephony dialer pre-addressed with the price of the content. In some embodiments, the wireless signal transmission / communication may include, for example, radio frequency identification (RFID), near field communication (NFC), Bluetooth, NBIOT, 3G, 4G, 5G, GSM, GPRS, WiFi, WiMax, CDMA, satellite, ZigBee, and / or other suitable wireless signals. In some embodiments, NFC can refer to a short-range wireless communication technology in which NFC-enabled devices are “swiped,” “bumped,” “tapped,” or otherwise brought into close proximity to communicate. In some embodiments, NFC can include a set of short-range wireless technologies, typically requiring a distance of 10 cm or less. In some embodiments, NFC can operate over the ISO / IEC 18000-3 air interface at 13.56 MHz and at speeds ranging from 106 kbit / s to 424 kbit / s. In some embodiments, NFC can include an initiator and a target. The initiator actively generates an RF field that can power a passive target. In some embodiments, this allows the NFC target to take on a very simple form factor, such as a tag, sticker, key fob, or card that does not require a battery. In some embodiments, NFC peer-to-peer communication can be performed when multiple NFC-enabled devices (e.g., smartphones) are in close proximity to each other.

[0103] Thus, in some embodiments, internet device 212 may be configured as a point-of-sale device for in-person micropayments for physical goods and / or services, such as at a physical vending machine. Internet device 212 may be used to generate a price for the physical item along with an identifier (e.g., SKU, SKURL), and then internet device 212 and telephony device 221 may be registered and / or paired for the price of the physical item. Thus, upon use of a wireless signal (e.g., RFID, NFC, Bluetooth, etc.), the wireless signal may instruct telephony device 221 to open a native telephony dialer pre-addressed with the price of the physical good and / or service. In one embodiment, pressing a connection (e.g., Green Phone) on the access control button 222 causes a call with an address signal listing the price for accessing the content to be forwarded through the radio access network (RAN) 223. The IN 220 performs AAA (Authentication, Authorization, and Accounting) procedures, which determine whether the account associated with the IN has sufficient credit ($0.10 in the above example) to complete the call. If credit verification is successful, the call and associated address signal (*10), including the forwarded MSISDN as the caller ID, are routed to the access control element 224. In some embodiments, upon receiving the address signal, the access control platform (e.g., the STARKEY platform) queries the access control ledger to determine whether a transaction is expected from the MSISDN for the signaled amount (e.g., 10c signaled by *10). In some embodiments, upon determining that a transaction is expected, the access control platform may effectuate and complete the transaction, for example, by performing the disclosed hook flash (WINK) signaling, and instruct the network to take the call OFFHOOK, thereby starting the clock for the call at the signaled amount (in this example, 10 cents).

[0104] In some embodiments, the access control platform instructs the network to replace the call ONHOOK, e.g., to then momentarily complete a hook flash, thereby completing the transaction. Upon replacing the call ONHOOK, the IN may generate a billing CDR for the transaction amount (10c) and debit or deduct the transaction amount from an account associated with the caller. In some embodiments, the access control platform waits for a signaling acknowledgment that the call has been network-disconnected. If the network indicates that the user disconnected the call (e.g., pressed the red phone icon) before the call went off-hook (e.g., sent a SIP CANCEL message to the access control platform), the IN 220 may abort the transaction and fail to complete. In some embodiments, upon determining that a transaction is expected, the access control platform (e.g., STARKEY platform) may register / receive and extract address signaling without going off-hook, as detailed herein. For example, if the address signaling of the present disclosure has no associated charge (e.g., no CDR), then the MNO element(s) may simply route the call or SMS to the access control platform (e.g., STARKEY platform) without further processing. In at least some embodiments, the novel SIP communication protocol of the present disclosure may use one of the following: 1) SIP INVITE> < 100 SIP BYE < 2) SIP INVITE> < 100 Click < SIP CANCEL.

[0105] In some embodiments, upon receiving signaling confirmation that the hook flash event was successfully completed, i.e., the CDR was successfully recorded and the amount deducted from the caller's account, the access control platform may update the access control ledger, mark the transaction from "set" to "met" and / or "successful," and communicate the same to the access control button 213. In some embodiments, upon receiving a micropayment confirmation indicating that the transaction is "fulfilled" and / or "successful," the Internet service may control which services or content are unlocked for access via the mobile device 212 / 221, for example, by downloading (access restricted) the Internet service via the data network connection 226, as displayed on the display 230 of the mobile device 212 / 221.

[0106] Thus, to make a payment for digital content and / or services, a user can dial the price indicated by the access control button 213 and unlock the content for consumption, for example, using a telephony call of one second or less. [Figure 3] Figure 3 depicts a payment network architecture in more detail in accordance with one or more embodiments of the present disclosure. Figure 3 graphically illustrates a massively parallel cellular transaction system and associated functional entity relationships utilizing a symbolic prefix and address signaling protocol and access control platform 310.

[0107] In some embodiments, the access control platform 310 hosts digital content that requires a micropayment for access. The access control button 311 displays the required amount to be paid (e.g., $N.NN or NNN¢). In some embodiments, the IN 320 is used to signal and implement the micropayment. In some embodiments, a preceding step may be performed to register and pair the user's cellular ID with the access control platform 310. In some embodiments, the cellular identity may include, for example, the user's MSISDN-Y. The registration of the cellular ID may be performed, for example, via a challenge and response method, user input, or other suitable registration technique for pairing the cellular ID with a particular anticipated transaction. This pairing ties the amount presented on the access control button 311 seen in the browser or APP, along with the registered cellular ID, with the access control platform 310 to uniquely bind and stage a pending transaction for content with the user. In some embodiments, because the requested payment ($N.NN) is uniquely bound (logically linked) to the user's registered mobile phone ID (MSISDN-Y), the systems and methods disclosed herein record this pending transaction in an access control ledger 370 (e.g., a record in a centralized database or a contract in a decentralized blockchain) that lists, for example, the MSISDNs where an NNN series address signal is expected.

[0108] In one or more embodiments, if the access control ledger 370 includes a blockchain, the pending transaction represented by the contract is subsequently fulfilled (satisfied) by receiving a cellular signal that matches the recorded expectation, thereby authorizing the transfer of funds to the content creator or publisher (@P). In some embodiments, the exemplary inventive computer-based system / platform, exemplary inventive computer-based device, and / or exemplary inventive computer-based component of the present disclosure interact with and / or utilize blockchain (distributed ledger technology), Ethereum (Ethereum Foundation, Zug, Switzerland), and / or other similar distributed data management technologies. For example, as utilized herein, a distributed database such as a distributed ledger ensures data integrity by generating a chain of data blocks linked to each other by cryptographic hashes of the data records within the data blocks. For example, a cryptographic hash of at least a portion of the data records within a first block, and possibly combined with a portion of the data records within a previous block, is used to generate a block address of a new digital identity block following the first block. As updates to data records stored in one or more data blocks are made, a new data block containing each updated data record is generated and linked to the preceding block with an address based on the cryptographic hash of at least a portion of the data records within the preceding block. In other words, the linked blocks form a blockchain that essentially contains a sequence of traceable addresses that can be used to track updates to the data records contained therein. The linked blocks (or blockchain) may be distributed across multiple network elements within a computer network, with each element maintaining a copy of the blockchain. A malicious network element attempting to compromise the integrity of the database would need to recreate and redistribute the blockchain more quickly than an honest network element, which is computationally infeasible in most cases. In other words, data integrity is ensured by multiple network elements within the network having copies of the same blockchain. In some embodiments, as utilized herein, a central trust authority for sensor data management may not be required to ensure the integrity of a distributed database hosted by multiple elements within the network. In some embodiments, the exemplary distributed blockchain ledger implementation of the present disclosure, along with associated devices, may be configured to effect transactions involving Bitcoin and other cryptocurrencies with each other and with (or between) so-called fiat or fiat currencies. In some embodiments, exemplary distributed blockchain-based ledger implementations of the present disclosure with associated devices are configured to utilize smart contracts, which are computer processes that facilitate, verify, and / or enforce the negotiation and / or execution of one or more specific activities between users / parties. For example, exemplary smart contracts may be configured to be partially or fully self-executing and / or self-enforcing. In some embodiments, exemplary inventive asset tokenization distributed blockchain-based ledger implementations of the present disclosure may utilize a smart contract architecture that may be implemented with a replicated asset registry and contract execution using cryptographic hash chains and Byzantine fault-tolerant replication. For example, each element of a peer-to-peer network or blockchain distributed network may act as a title registry and escrow, thereby effecting changes of ownership and implementing a set of predetermined rules governing transactions on the network. For example, each element may also check the behavior of other elements, potentially acting as a miner or validator, as described above.

[0109] In some embodiments, the inverse association between an activated access control button 311 to purchase a uniquely identifiable digital product online (e.g., via a SKU or other identifier for content and / or services) and the expectation of waiting for a matching cellular signal from a known MSISDN allows a user to dial the sticker price ($N.NN) without entering additional beneficiary address information to which the resulting micropayment will be directed. In some embodiments, this transactional simplicity and unified addressing protocol that binds the signaled price with the content and / or service provider is achieved based on the inverse association between the payer and the payer and the resulting expected value set for the selected content and / or service. Thus, the mapping between the cellular micropayment signal, the digital content being purchased, and the provider is all seamlessly stitched on the backend within the access control ledger 370, as disclosed, and is therefore completely transparent to the consumer (originator).

[0110] For example, a digital product or service SKU from provider @P, requesting an NNN¢ ($N.NN) micropayment from MSISDN-Y, and having an access control button 311 activated at date timestamp DT, may result in the following expectations and associated metadata (where " / " indicates a record field separator), as depicted in access control ledger 370: [Y:NNN / @P / SKU / DT]. Thus, in some embodiments, when an address signal *NNN is received from MSISDN-Y, if the cellular wallet (e.g., 333) associated with MSISDN-Y has a sufficient credit balance to maintain the NNN fee, provider P is credited for the sold SKU and a date timestamp (DT) of the new transaction is recorded. By recording an initial timestamp of at least one activity associated with the Button (e.g., Button activation (e.g., click / select)), the access control platform can release upon timeout during intervals when no such cellular signal is received, freeing up unused communication resources. In some embodiments, a specific sequence of address signals may be expected from a known MSISDN according to expectations set in the access control ledger 370. Thus, in some embodiments, the access control platform 310 may use transaction prediction to ensure that only the correct address signals, and consequently the correct payment amount, are accepted for processing. Thus, if a user mistakenly dials *001 (1 cent US) when a pending transaction is expecting *010 (10c), the access control platform 310 may harmlessly reject the transaction due to the lack of a matching expectation. Thus, the access control platform 310 may avoid engaging with the disclosed hook flash signaling protocol, which would erroneously execute an arbitrary transaction that debits a cellular account for an incorrect amount.

[0111] In some embodiments, cellular signaling of address signals mapped to internet endpoints and products enables highly parallel transaction processing, where many users (thousands, if not millions) may all simultaneously, or substantially simultaneously, view the same digital content and request the same micropayment, and then all simultaneously, or substantially simultaneously, emit the same signal to conduct the same micropayment transaction, all without interference signaling unique transactions that could inadvertently authorize access and delivery of content from one consumer to another. Thus, in some embodiments, by setting the transaction expectation [Y:NNN], only telephony devices having MSISDN-Y transmitting address signal NNN and associated cellular wallets [Y] with sufficient balance to sustain the $NNN charge per the disclosed method and system can unlock content (SKUs) associated with an activated $N.NN access control button 311 presented to the user. This highly coordinated, tiered, one-to-one, many-to-one, many-to-many, user-to-content relationship building, as disclosed, enables more efficient and secure micropayments at scale.

[0112] 3 shows three such access control platform expectations and resulting transactions from three users, each recorded in the access control ledger 370 before the user issues the associated address signal. These expectations (312) set in the access control ledger 370 may further record transaction metadata, including but not limited to: the unique identity of the digital publisher (@P) presenting the access control button 311 (which in some embodiments is the MSISDN itself. Thus, the digital publisher's unique identity (@P) describes a provider access control wallet 380[*P] that can be registered as a key for the content publisher using registration and / or pairing techniques similar to those described above for the user's telephony device, e.g., using the access control platform API; A stockkeeping unit (SKU) that identifies the digital content or service you are purchasing · The button activates a timestamp (for example, in the format YYYYMMDDHHMMSSMMM from years to milliseconds or any other suitable timestamp format). Thus, in some embodiments, cellular user A with MSISDN-A (330), cellular user B with MSISDN-B (340), and cellular user C with MSISDN-C (350), etc., may view the same or different access control buttons 311, govern access to the same or different digital content, require the same or different payment amounts, and be securely signaled substantially simultaneously in parallel.

[0113] In some embodiments, on each A, B, C telephony device emitting a respective NNN series address signal, IN320 performs an AAA (Authentication, Authorization and Accounting) step, the latter step determining whether each of the cellular accounts [A], [B], [C] associated with callers (A), (B), (C) has sufficient credits ($N.NN) per direct mapping of the address signal to a monetary value to complete call setup and pending microtransactions. In some embodiments, if the account can sustain the associated charges, e.g., 2¢ for cell A, 99¢ for cell B, and 10¢ each for cell C, the call passes accounting validation and is routed to access control platform 310 (e.g., based on a symbolic prefix and / or equivalent internal routing short code). In some embodiments, access control platform 310 may then query access control ledger 370 as a pre-transaction validation step to determine whether an incoming signal is expected from the respective telephony device. In some embodiments, the transaction is only executed on the condition that the active payment expectation (312) matches the address signal (322) received from the expected cell MSISDN-Y, thus uniquely ensuring that the cellular user cannot mis-dial the payment amount. In some embodiments, once the expectations are met for each cellular user, the access control platform 310 executes a hook flash signaling protocol to cause the IN 320 to generate a CDR and complete the corresponding transaction. In particular, a CDR may be generated upon receiving an acknowledgment that the associated cellular user's call has been disconnected by the access control platform 310, and not by the cellular user. In some embodiments, a conditional network disconnection, which causes the access control platform 310 to create a disconnect CDR, prevents a user from issuing a mid-call setup ABORT by pressing the phone connect button and then momentarily pressing the phone disconnect button for a period of time such that the address signal has sufficient time to reach the access control platform 310, while corrupting the transaction by avoiding the generation of a CDR. In some embodiments, CDRs are used to debit a price from an account associated with the cellular user, so disabling the generation of a CDR aborts the transaction. In some embodiments, upon receiving a successful transaction completion indication (e.g., a positive access grant indication), the access control platform 310 can then update the access control ledger (370) to record the completed transaction and timestamp and debit the provider access control wallet 380 [*P] to reflect the outstanding amount. The access control platform 310 then communicates to the Internet Endpoint (IPE) and the provider (@P) that the transaction for the associated SKU item is complete and authorizes the unlocking of the digital content, thereby granting content access to the user via the IAPP. In some embodiments, the provider receives a UUID that uniquely identifies the transaction.

[0114] This expected and verified signaling protocol ensures that the payment amount transmitted in the cellular address signal has been debited to the cellular user account before granting access to the digital content. Thus, in the illustrated example, three micropayment transactions arrive at approximately the same time from three telephony devices, debiting the following three chronologically ordered cellular accounts (wallets): [B] - $0.02 (344) [A] - $0.99 (333) [C] - $0.10 (355). And cumulatively, system register (wallet) credits are generated in the access control platform. [ * ] = [ * ] + $1.11 (360). Thus, the access control platform 310 acts as a micro-clearinghouse for content publishers. The cumulative access control platform register (360) is determined by the sum of all access control platform-related CDRs in a defined transaction billing period (e.g., daily, weekly, monthly), as a series. [A, *NNN] + [B, *NNN] + [C, *NNN] .... In some embodiments, IN 320 may charge a micropayment switching fee (%X) for the transaction conducted. Similarly, access control platform 310 may charge a transaction processing fee (%Y). Content publishers may then accumulate cumulative balances in their associated access control platform wallets 380[*P] with each $N.NN transaction completed as follows: [*P] = [*P] + ((100 - X - Y) / 100 x $N.NN).

[0115] In some embodiments, this may result in rewarding a majority (85%) of microtransaction content publishers with a 10% IN 320 fee and a 5% access control platform 310 fee. Thus, the payments may include a genuine and sustainable revenue share. After deducting any percentages of switching (%X) and transaction (%Y) fees, the access control platform 310 may distribute the net payment revenue accrued to each provider (PA, PB, PC) for each transaction by debiting their respective access control platform wallets 380 according to the example above: [*PA] = [*PA] + (100 - X - Y) / 100 x 0.99 [*PB] = [*PB] + (100 - X - Y) / 100 x 0.02 [*PC] = [*PC] + (100 - X - Y) / 100 x 0.10. In some embodiments, these funds may be marked as “pending” until such time as the IN 320 finalizes payment to the access control platform 310 . In some embodiments, an Internet Application (IAPP) on a user's telephony device may utilize the API to request a micropay transaction, which renders an access control button 311 user interface element that displays the sticker price. In some embodiments, the access control button establishes a two-way communication channel (e.g., a socket connection) between the access control element and the IAPP or IPE.

[0116] Such a two-way communication channel allows IN 320 events to be pushed to the Internet-enabled access control button 311. In some embodiments, the access control button 311 thus provides a live transactional payment channel between the telephony device, IN 320, and the Internet application in a single, self-contained user interface element. In some embodiments, the two-way communication channel carries signaling in substantially real time between mobile phones, cellular switches, internet-based access control elements, and access control buttons including internet buttons, etc., in accordance with the disclosed methods and systems, along with micropayment expectations that uniquely identify and bind symbolically prefixed address signals from known cellular device IDs matched to digital content or services at a signaled price, as disclosed. [Figure 4A] 4A depicts a logical representation of an exchange IN 460 (e.g., a telephony network) and a device A 450. In some embodiments, this architectural abstraction depicting the core elements in an access control platform transaction may omit some elements for clarity. Some embodiments may have different allocations to physical elements than shown; however, the physical separation of logic shown does not affect the disclosed modeling.

[0117] In some embodiments, device B 420 connected to the Internet 410 displays a screen requesting a user of the access control platform to access digital content or services. Device B 420 may include an Internet-enabled mobile phone with an Internet browser that links to a web page or an APP that renders Internet content or services. Alternatively, device B 420 may be a personal computer with an Internet-connected browser or software. In this manner, device B 420 and cellular telephony A 450 may be one and the same physical device.

[0118] In some embodiments, upon rendering a screen for an access control platform transaction, device B 420 connects to access control element 440 via a published API to request access control button (430). In some embodiments, the API allows the IAPP to specify the access control platform transaction amount (e.g., NNN¢ and *NNN address signals as disclosed herein) along with the SKU to be purchased. Each element rendered on the screen requesting access control platform functionality may be further identified by a unique digital ID linked to the transaction. In some embodiments, if device A (450) has previously performed an access control platform transaction using IAPP and is registered and / or paired for a pending transaction as described above, then an expectation may be set in the access control element (440). In some embodiments, the expectation may include a signal from a device identified by MSISDN-A emitting a *NNN address signal. This expectation may be annotated herein with the annotation [A:NNN], for example, although any other suitable annotation may be employed. In some embodiments, the access control platform API establishes bidirectional communication between the access control element (440) and the STAR button (430), allowing transaction events to be communicated between them. One such bidirectional communication protocol utilizes IP sockets. In some embodiments, tapping the access control button (430) activates the transaction and associated channel and prompts the user to dial the *NNN address. While the access control button (430) may be activated automatically, because multiple buttons may appear on a single screen, each associated with different content / services, tapping or moving focus to activate the access control button (430) may be a mechanism for selecting the desired item to purchase.

[0119] In some embodiments, User A may dial *NNN on Device A 450 to represent payment in dollars ($N.NN). In another embodiment, User A may dial *NN or *0NN (with leading zeros) to represent payment in cents (NN¢). Transaction signals may be transported over the IN 460 (e.g., a Radio Access Network (RAN)) using, for example, TDMA / CDMA signaling or Session Initiation Protocol (SIP). In some embodiments, a symbolic prefix, such as a star, hash, or ampersand, in a cellular address signal is accessed by touching a symbol key (470). For example, a star may be used for the symbolic prefix, in which case the symbol key 470 may be the star key located at coordinates R4C1 (row 4, column 1) in the cellular dial pad matrix. In some embodiments, the symbolic prefix may route the call to the access control element (440) along a star-configured trunk or a universal resource indicator (URI). In some embodiments, dialing *NNN causes the mobile originating switching element (e.g., MSC 480) to enter the Originating Basic Call State Model (OBCSM) and encounter an Initial Detection Point (INITDP:DP2 Collected_Info). INITDP establishes a call control dialog with no Service Control Point (SCP / gsmSCF) indicated. In some embodiments, this MSC / SCP dialog is established utilizing the MAP / SS7 signaling protocol. In some embodiments, the SCP performs a credit verification for user A by querying a cellular wallet (490), which is an account associated with device A 450, to determine whether A has sufficient credit to complete the call. That is, in this example, it determines (490) whether user A has at least $N.NN credit in the associated cellular account according to the disclosed mapping. In some embodiments, the cellular wallet 490 is managed by an IN charging system, or an online charging system (OCS).

[0120] In some embodiments, once User A determines that he has sufficient credit, the SCP instructs the MSC (480) to continue the call, which then routes the call request to the access control element (440). In one switching embodiment, the MSC routes the call along the associated symbol (e.g., star) trunk to the GMSC / SBC, which then converts the ISUP to SIP signaling. In some embodiments, while Figure 4A depicts the MSC 480 connecting to the access control element (440) over a straight path and a single hop over the cellular wallet (490), that is merely illustrative of the logical entity relationships within the described channel. That is, the cellular wallet (490) may not actually be connected to the access control element (440) at all and may not be involved in the call signaling path and any protocol conversion. The actual network route, protocol, and associated links for cellular wallet 490 access are not shown for clarity. In some embodiments, upon receiving the call request access control element (440), the access control element (440) determines whether the call is from MSISDN-A, and the sending address signal NNN is expected (i.e., the record [A:NNN] exists), and activates the access control button 430 configured for the user. If such expectation is met, the access control element (440) may instruct the MSC (480) to present a ringback tone (RBT) to device A (450), and then instruct the MSC 480, according to the hook flash signaling protocol disclosed herein, to temporarily take the call OFF / HOOK, and then temporarily replace the callback ON / HOOK to carry out the transaction. Thus, in some embodiments, the user experience of the access control platform: 1. Instant ringback tone followed by 2. Instant call connection and disconnection.

[0121] In some embodiments, the telephony device (450) may then display the call symbolically prefixed with a duration of 00:01 seconds. In some embodiments, the flash protocol thus presents both audible (ringback tone) and visual (instant connect) confirmation, where the call picks up, connects, and then drops upon completion. The hook flash signaling disclosed herein generates a $N.NN call data record (CDR) billing ticket on the MSC (480) for the star dialed number NNN. In prepaid cellular embodiments, this amount is debited to the cellular wallet (490) substantially in real time. In some embodiments, upon receiving confirmation from the MSC (480) that the hook flash protocol has been successfully completed and confirming the CDR generation, the access control element (440) may communicate to the access control button (430) that the transaction was successful. Upon receiving a successful indication (e.g., a positive access authorization indication), the access control button (430) may then change state, for example, presenting a positive icon, such as a check mark, to reflect payment completion before unlocking access to the digital service or purchased content.

[0122] In some embodiments, once the transaction is successfully completed, the access control element (440) may then record the access control platform transaction amount in a cumulative access control wallet 499 (STAR ​​wallet) and record the amount due to the provider (minus any switching and processing fees) in an access control wallet (not shown) associated with the provider. In some embodiments, upon receiving payment confirmation, the IAPP grants access to the requested content / service and completes the transaction. The access control element (440) may therefore coordinate, route, and translate cellular signaling events into transaction events, synchronizing events on the IN 460 with events on the Internet. This signaling convergence therefore seamlessly transitions cellular billing certificates to the cloud while maintaining reliable transaction records in the form of CDRs. In some embodiments, device B (420) and device A (450) may be one and the same smartphone device, so that the user may not need to manually enter the star address signal (*NNN) to dial. Rather, upon touching the access control button (430), the access control button 430 may issue a command to device A / B 420 / 450 to present a native or selected dialer on the telephony device (420 / 450) with the address signal corresponding to the price on the access control button 430 automatically entered. To automatically launch the dialer in this pre-addressed manner, the access control button (430) embedded in a web page may have an associated "tel:" reference, for example: *025 .

[0123] In some embodiments, while such a telephony URL reference in some embodiments opens a telephony dialer with the address already entered, the user may then be required to CONNECT the call (e.g., by pressing the green phone button). A cellular APP with the necessary telephony call control permissions and associated access control platform logic may perform more advanced call control via APIs to the native dialer and allow one-touch connection. In either case, the typical elapsed time between tapping the access control button and completing the payment transaction is only a few seconds. In some embodiments, the access control platform provides a virtual fingerprint payment system because the symbol key (470) (e.g., star, hash, ampersand, etc.) on mobile phone A (450) is logically bound in this manner and synchronized to an expected, activated, individual access control button (430) on the Internet. The unique mapping between the symbol key and the access control button 430 enables simultaneous access control platform transactions to be uniquely signaled and switched, even though all transactions may be uniformly presented and signaled substantially simultaneously. As noted above in FIG. 3, this mass atomic binding between the symbol key and the access control button 430 is a function of the uniquely phased expected signal and is embodied in the access control platform transaction protocol.

[0124] In some embodiments, up to millions of users, all potentially viewing the same access control buttons governing access to the same Internet content on the same Internet page, are required to emit the same cellular signal at substantially the same time, all independently and securely switched. The star signal has a 1:1 relationship with an expected, known, and identified MSISDN. This secure digital cellular circuitry ensures that when multiple cellular users are transacting simultaneously using the disclosed protocol, the "cellular wires" never cross, so to speak, and therefore prevents A from inadvertently dialing and paying B. In some embodiments, the two-way star button communication channel allows the access control platform to signal and visually alert the user. For example, if the user dials an incorrect sequence of digits to that expected by the access control element, i.e., the expected value of [A:NNN] is not met, the button can "shake" NO (e.g., animate left / right / left / right) to indicate that an incorrect payment attempt was made, thereby signaling the user to try again without incurring any costs. [Figure 4B] FIG. 4B shares annotations with FIG. 4A, except that the numeric labels have the letter "B" appended to them, which is a channel representation of an IMS / VoLTE packet-switched telephony network (480B) and associated user equipment (450B). In this IMS / VoLTE embodiment, the channels are logically executed in the same sequence and series as described in Figure 4A, with this distinction applied to the elements depicted to the left of Cell WALLET (490), which utilizes SIP rather than ISUP signaling to set up calls, and elements that may utilize SIP and DIAMETER rather than the traditional SS7 / MAP protocols for account management and credit verification. [Figure 5]

[0125] 5 illustrates an access control button transition series in accordance with one or more embodiments of the present disclosure. The following series assumes that a cellular MSISDN-A has been pre-paired with an IAPP that displays an access control button 511. In some embodiments, as described and disclosed in Figures 4A and 4B above, the access control button is a self-contained user interface element communicatively coupled to the access control platform, overcoming a technical problem common to all transaction systems that, in some embodiments, presents separate screens or dialogs to communicate status. Separate user interfaces that switch display context to communicate transaction progress visually detract from the user and the overall payment experience, impacting operations. The active, in-channel, communication button disclosed herein contains all payment communication and status in a single user interface element, uniquely overcoming these current transaction design limitations. block uIn the example, the access control button 511 is partitioned to display the item price on the left (10¢) and the current icon (action / state) on the right (*). Upon loading, the access control button 511 enters an initial state, which in some embodiments is displayed as series 512: Color: Red, indicates that the transaction is stalled Status: Locked, access to digital content / services prohibited Phase: Inactive. So 512 represents an inactive access control platform channel combined with a locked digital item selling for a 10 cent sticker price. In some embodiments, activating the access control button 511, for example by tapping or clicking the access control button, transitions the series to block 520, where the access control button 511 then establishes communication with the access control platform to set payment expectations, which, among other things, records the association between the cellular MSISDN-A and the payment amount [A:010], as described above.

[0126] In some embodiments, the expectation further records and associates the provider and product identifiers for this button and the pending transaction, as illustrated in Figure 3 (ledger 370). During this communication establishment, in some embodiments, the access control button 511, currently labeled 521, transitions (pivots) to series 522: Color: Orange to indicate state shift Status: Connecting Phase: I look forward to it. In some embodiments, during this 520 transition, the button rotates from displaying the price on the left to displaying the address signal *010, which represents the monetary value of the transaction ($0.10), and a telephone icon on the right. In some embodiments, the telephone icon indicates that a dialing action is required. The color indicates that the button is at the SHIFT signal. In some embodiments, displaying the price and star symbol (10¢ and *) on access control button 511 pivots or otherwise transitions to reveal the back of the button displaying the dial string (*010) and phone icon on access control button 521. In some embodiments, the transition visually synchronizes the transition from sticker price to dial string, indicating a direct mapping between dollar ($N.NN) digits and star (*NNN) address signals. In some embodiments, once communication is successfully established, the access control button 523 transitions to a series 523, and in this signaling embodiment: Color: GREEN signaling GO Status: Connected Phase: Signaling.

[0127] In some embodiments, at this stage, the access control button 521 may prompt the user to dial the displayed digits. In some embodiments, this dialing action is manually engaged in by tapping the now green button. In other embodiments, the dialing action is automatic upon successful establishment of communication. In either case, if the device supports telephony functionality, the dial action will invoke and launch the native telephony dialer with the dial string (*010) automatically entered, as described above in Figure 4. If the paired cellular device is physically different from the device displaying and displaying the access control buttons, the user can manually enter the short dial string (*010) on the cellular telephony device (e.g., smartphone / mobile phone).

[0128] In some embodiments, upon dialing from the paired MSISDN-A and thus issuing the expected access control platform address signal (*NNN), the access control platform is communicatively coupled to the active and connected access control button and verifies the transaction as described above. If the transaction is successfully completed, the access control button 521 transitions to block 530. death, In some embodiments, the access control button 531 is again rotated to display the original price on the left (10¢) and a check mark icon on the right. In some embodiments, an audible and / or visual indicator may be emitted to confirm success, such as a coin dropping sound or other indicator. In some embodiments, this transaction is signaled and completed in as little as one second, as described and illustrated below in FIG. 6. Series 533 provides visual confirmation of the completed transaction in this signaling embodiment: Color: Blue, signaling communication and transaction is complete. Status: Unlocked, allowing access to digital content / services Phase: Transaction. In some embodiments, the final (blue) transaction state "nods" the user affirmatively YES by animating the button in an up, down, and up sequence to indicate approval. In some embodiments, a sound bite may be played at each transition for an audible alert (e.g., the sound made when a coin is dropped into a glass tip jar). Once payment is complete, the screen unlocks and the purchased items are displayed. In URL-driven content access embodiments, successful payment may redirect the APP / Browser to the completion URL, displaying the unlocked content. In some embodiments, if any error condition is encountered during any phase, the series may transition to block 540, and in some embodiments, the button reverts to a red error state with a cross icon on the right and the error that occurred on the left (e.g., transaction timed out, incorrect number dialed, user canceled, etc.). In some embodiments, the button may rock negatively to signal NO by animating left and right. Thus, error series 544 may exhibit the following: Color: Red, as if the transaction has stopped Status: Error, indicates cause Phase:Cancel, button may be reset.

[0129] In some embodiments, the access control button and the described transition sequence present a highly interactive, responsive, and contained payment signaling and processing channel. In some embodiments, the access control button is rendered in an iframe that overlays the content so that it floats above the provider page. [Figure 6] 6 depicts an example of an access control platform microtransaction switching timeline on the millisecond axis, highlighting a flash sub-second switching protocol in accordance with one or more embodiments of the present disclosure. In some embodiments, the elapsed time (T) between the switching element and the charging element is approximated for illustrative purposes, and the timeline is not drawn to scale. Switching and validation are measured in single-digit milliseconds in some embodiments. T = 0 ms: At 610, the user presses SEND to issue an access control platform address signal (*NNN) encapsulating the disclosed $N.NN transaction amount. T = 10 ms: At 620, the cellular network performs AAA (Authentication Authorization and Accounting) procedures and routes the call towards the access control platform if it passes an accounting check verifying that the account associated with the caller has sufficient credit to sustain the $N.NN charge. T = 20 ms: At 630, if the access control platform determines that the *NNN address signal received from the cell is from the expected MSISDN-A and matches the amount on the access control button, satisfying that expectation, it executes the WINK protocol, puts the call into OFF / HOOK, and then pauses for an appropriate period of time, e.g., 1 second or less, 500 milliseconds, etc. T = 520 ms: The access control platform returns the call ON / HOOK, generates a 1-second cellular billing certificate on the cellular network for the signaled amount of $N.NN, and IN debits the cellular wallet. T = 521 ms: In some embodiments, the access control platform credits the access control platform wallet associated with the access control platform and the provider wallet associated with each provider. The access control platform completes the transaction and the call ENDS (640). The total elapsed time is less than 1 second.

[0130] In some embodiments, the access control platform micropayment protocol may therefore make payments over microsecond switched telephone calls. Furthermore, the access control platform's payment protocol operates using native telephony signaling channels along the call setup and billing control path, and operates seamlessly using existing digital cellular wallets, making the access control platform invisible to the user (i.e., zero footprint) on every phone. [Figure 7] FIG. 7 depicts an abstract billing diagram of the disclosed access control platform micropayment protocol, in accordance with one or more embodiments of the present disclosure. Item 710 depicts telephony device A issuing a star address signal (e.g., *NNN) signaling payment for a transaction value of $N.NN. Item 720 shows the Off / On-Hook Toggle feature (power icon) that passes the accounting check, connects the call (goes OFF / HOOK), and then temporarily disconnects the call (returns ON / HOOK). Item 730 indicates the charging function (plus / minus polarity), in which the caller's mobile phone wallet is debited (-$N.NN) and the access control platform's system wallet and provider wallet are credited (+$N.NN minus switching and processing fees). In some embodiments, the access control platform payment protocol may similarly be depicted by the following textual schematic diagram: (*)- / \\ / -(+ / -) (*) represents the star address signal (*NNN). / \ represents the OFF HOOK state. \ / represents the ON HOOK state. (+ / -) represents a wallet charge transaction (+ / - $N.NN). [Figure 8] FIG. 8 is a flowchart depicting prior art mobile phone billing. As shown in FIG. 8, a user may be presented with multiple payment methods and required to manually select a desired option. In flow item 800, the IAPP presents a purchase price for content or services. This purchase price is an informational display, rather than an active payment user interface element, to inform the user of the transaction amount. In flow item 801, the IAPP then presents multiple payment methods by presenting multiple payment buttons logically coupled to the items and the displayed purchase prices. In flow item 802, the user selects a desired payment method by activating (e.g., tapping or clicking) the corresponding payment button. If the mobile phone payment button is selected, the flow moves along the affirmative YES path to item 803. In flow item 803, the IAPP implements the mobile phone billing method selected by the user.

[0131] In some embodiments, multiple payment options, given the frequency with which they are encountered, introduce manual decision points and obstacles to mass adoption and frictionless flow of micropayments, slowing cellular billing methods for low-value (micro) transactions. [Figure 9] 9 is a flow sequence illustrating cellular micro-charging via an access control platform in accordance with one or more embodiments of the present disclosure. In some embodiments, as shown in the sequence of FIG. 9, embodiments of the present disclosure enable elimination of manual payment selection by automatically selecting cellular charging for transactions below a maximum threshold amount. In some embodiments, a purchase price threshold of one dollar (USD) automatically selects and presents a cellular payment method button displaying the micro-purchase price. At flow item 900, if the purchase price of the content or service is below a predetermined threshold, the flow travels along the affirmative YES path to item 901. In flow item 901, the IAPP automatically switches the payment method to mobile phone and displays a mobile phone payment button displaying the micro-purchase price. Thus, whereas in the current state of the art as described above in FIG. 8, an IAPP may present and display the purchase price separately from the access control button given the existence of multiple payment methods, the disclosed micro-payment system and method presents a unified method and price to a single access control button determinant of the price being below a maximum threshold.

[0132] At flow item 902, when a user activates an access control button (eg, an access controller interface element), flow travels along the affirmative YES path to item 903 where the IAPP implements the cellular payment method. [Figure 10] FIG. 10 is a diagram illustrating a prior art mobile phone billing interface. The IAPP screen 1000 displays content or service 1010 with a static (inactive) purchase price element 1011 ($9.99) in a dotted line, separating it from multiple payment buttons and associated methods 1020-1030. Multiple payment methods may include options such as credit card (VISA), PayPal (PPAL), Apple Pay (APAY), Google Pay (GPAY) and cellular billing (CELL 1030). Thus, the above display presents the user with a single product or service (1010) with multiple payment methods (1020) and requests the user to make a manual payment selection. [Figure 11A, Figure 11B] 11A and 11B depict an exemplary cellular micro-access control application program interface enabled by an access control platform according to one or more embodiments of the present disclosure. At least some embodiments of the present disclosure enable the elimination of manual payment selection requirements by automatically switching to cellular access control billing for transactions below a maximum threshold amount (e.g., $1.00). In providing a technically improved access control application program interface configured for specific access restriction items down to a single selection, in at least some embodiments, the exemplary disclosed systems and methods of the present disclosure, in some embodiments, provide at least one technical solution that mates with website designs that render multiple access-restricted content items, such as articles, links, and services per web page. 11A, display screen 1100 thus shows multiple access-restricted items for purchase with a single directly associated cellular payment access control button (e.g., access controller interface element) displaying a micro-purchase price that can be utilized as an access code, e.g., item 1110 with access controller interface element 1111 for $0.99, item 1120 with access controller interface element 1121 for $0.10, item 1130 with access controller interface element 1131 for $0.25, etc. 11B , display screen 1100 also shows multiple access-restricted items for purchase, each with a single directly associated mobile phone payment access control button (e.g., access controller interface element) that displays a micro-purchase price that can be utilized as an access code. For example, item 1110 with access controller interface element 1111A and access code label 1111B for $0.99, item 1120 with access controller interface element 1121A and access code label 1121B for $0.10, item 1130 with access controller interface element 1131A and access code label 1131B for $0.25, etc. In some embodiments, the access code labels are displayed in a 1:1 ratio with the access controller interface elements, for example, without limitation, thereby providing another technical solution that ensures a unique logical and visual relationship between the access codes and the access controller interface elements. In some embodiments, the access code label is displayed, for example and without limitation, in visual proximity to the access controller interface element (e.g., less than 2 inch separation distance, less than 1 inch separation distance, less than 0.5 inch separation distance, less than 0.2 inch separation distance, etc.), thereby providing another technical solution that ensures a unique logical and visual relationship between the access code and the access controller interface element. [Figure 12A]

[0133] 12A illustrates a microchip scheme using an access control platform, where an IAPP allows a user to access and consume content before requesting any payment in lieu of a tip, in accordance with one or more embodiments of the present disclosure. In some embodiments, an IAPP screen 1200A displays content 1210A (e.g., Item A) unlocked for consumption along with a cellular chip access control button 1220A. Thus, a user can decide what value they derive from the freely accessible content and what compensation, if any, they feel is due to the creator. [Figure 12B] FIG. 12B illustrates a tip menu 1220B in a Micro Gratuity Scheme using an access control platform according to one or more embodiments of the present disclosure. In some embodiments, the tip menu 1220B may present multiple nominal amounts upon actuating (e.g., tapping / clicking) the tip access control button 1220A. The user may then select an amount to contribute to content creation. In some embodiments, the IAPP may display average or most common gratuities to guide the user's selection. Once the gratuity amount is selected, the mobile phone payment is made as disclosed. In some embodiments, the microchip scheme inverts the commercialization of content and replaces it with an honor system where value is not determined by producers, but can be freely determined by consumers, the market. [Figure 13A, Figure 13B] 13A and 13B show alternative views to FIGS. 10 and 11, again highlighting at least one technical distinction between a technical drawback and at least one technical solution according to at least some embodiments of the present disclosure. 13A illustrates a technical drawback of a circuit that is a payment stack that presents multiple payment methods that a user is required to manually select. In one embodiment, as shown in FIG. 13B, at least one technical solution of the present disclosure establishes an automatically assigned, single activity channel 1310, an access control microcircuit that may display a determining factor, for example, without limitation, regarding the purchase price being below a threshold.

[0134] [Figure 14] FIG. 14 graphically depicts the resulting transaction distribution curves, plotting frequency against magnitude, for multiple payment methods and options 1400 offered for MACRO and MINI amounts, versus a single cellular payment method 1410 offered for MICRO amounts. The low frequency of MINI CELL transactions (e.g., $10) is primarily due to the fact that these transactions have to compete with several more established, well-known, and habitually used payment methods, as mentioned above. The high-frequency MICRO payment prediction is based on the positive psychological impact of a single frictionless mobile payment method and ultra-low transaction values ​​(e.g., 10 cents). MICRO Payments doesn't force users to choose a payment method, but rather funnels all micropayments seamlessly and quickly through express cellular checkout lanes, removing any friction from the purchasing decision. [Figure 15A] 15A illustrates an example of a custom rating model of an IN charging element programmed to use the custom rating model to determine communication charges (fees) using the address signaling of a call in accordance with one or more embodiments of the present disclosure. In some embodiments, the custom rating model may include a dynamic (continuously) calculated charging matrix that maps any star-N address signal to its direct monetary equivalent as follows: Line 151A, two *NN digit address signals parsed into min / max 0 / $0.99 charges. Row 152A, three *NNN digit address signals parsed into min / max 0 / $9.99 charges. Line 153A, the four *NNNN digit address signal, is parsed into a min / max 0 / $99.99 charge. Line 154A, the five *NNNNN digit address signal, is parsed into a minimum / maximum 0 / $999.99 charge. Line 155A, any *N serial digit address signal parsed into min / max 0 / N charges; and Row 156A, any N sequence up to 5 digit address signal parsed into min / max 0 / N charges. In some embodiments, there may be a 156A digit limit, for example, a maximum of 5 digits. Such a limit, in some embodiments, is to ensure that non-star-dialed micropayment address signals do not intersect with a subscriber's telephone number space.

[0135] In some embodiments, the access control platform presents users with a transparent billing protocol, as the digits dialed directly equate to the cost of the transaction, therefore, decimal by decimal. In some embodiments, a user may dial any payment amount using the signaling methods and notations described above. In some micropayment embodiments, two digits (NN) enumerate and encapsulate payments between $0 and $1 ($0.01-$0.99), enabling technical solutions to the technical problems described above, including efficient and verifiable microtransactions with authoritative records in the form of CDRs. In some embodiments, any other suitable number of digits may be used. For example, a three-digit embodiment (NNN) is best suited for clarifying dollar and cent notations to avoid misunderstandings regarding the actual transaction value; for example, 10 cents may be presented as *010 rather than *10 (e.g., *10 may be interpreted as signaling $10). [Figure 15B] 15B shows additional details regarding an example custom rating model of an IN element programmed to use the custom rating model to determine call charges using a call's address signaling in accordance with one or more embodiments of the present disclosure. In some embodiments, the custom rating model may present a static (discrete) micro-charging matrix, or rating table, that matches two-digit (NN) or three-digit (NNN) address signals to their direct monetary suitability. Line 151B: Address signals *00 or *000 are converted to a charge of $0.00. Line 152B: Address signals *01 or *001 are converted to a charge of $0.01. Line 153B: Address signals *02 or *002 are converted to a charge of $0.02. Line 154B: Address signals *05 or *005 are converted to a charge of $0.05. Line 155B: Address signals *10 or *010 are converted to a charge of $0.10. Line 156B: Address signals *25 or *025 are converted to a charge of $0.25. Line 157B: Address signals *50 or *050 are converted to a charge of $0.50. Line 158B: Address signals *75 or *075 are converted to a fee of $0.75; and Line 159B Address signals *99 or *099 translate to a charge of $0.99. Thus, a user can dial *01 (Star Zero One) to pay 1¢ from their mobile wallet. Similarly, a user can dial, for example, *02, *05, *10, *25, *50, *75, or *99 to pay 2¢, 5¢, 10¢, 25¢, 50¢, 75¢, or 99¢, respectively. For larger amounts, users can dial a longer series of matching digits, as shown previously. For more discrete amounts, users can dial the middle representative digit (e.g., *03 = 3¢ (US cents)). Additionally, in some embodiments, a user may dial dollar-normalized notations such as *001, *002, *005, *010, *025, *050, *075, *099 for matching denominations. In some embodiments, a user may dial the appropriate monetary digit sequence without the need for a symbolic (e.g., star) prefix, such as dialing 001, 002, 005, 010, 025, 050, 075, 099, where all such three-digit telephone numbers may be automatically converted by network switching and control elements to a star or appropriately prefixed number for routing to such a micropayment processing platform.

[0136] In some embodiments, the above billing modifications are accomplished by manually programming the element of the IN to populate an IN rating table stored in non-transitory memory with entries supporting the allowable discrete micropayment amounts (signals). That is, for each micropayment (e.g., 1¢, 2¢, 5¢, 10¢, etc.) provided by the IN, a new entry is inserted into the rating table corresponding to the address signals of these discrete micropayments (rows *001 => 1¢, *002 => 2¢, etc.). Thus, to support the micropayments in Table 15B above, the element of the IN may be programmed to add nine new rows to the rating table. In some embodiments, non-transitory memory may include any medium and / or mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, machine-readable media may include read-only memory (ROM); random-access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustic, or other forms of propagated signals (carrier waves, infrared signals, digital signals, etc.), and the like.

[0137] In one or more embodiments, the IN billing system programmatically determines the applicable rating tariff by calculating the appropriate integer of the *NNN address signal. In one embodiment, the calculation may include, for example, the following: 1) Extract the NNN digits using string operations on the *NNN address signal to remove the symbolic prefix; and 2) Use a PARSEINT type instruction to convert the resulting NNN string to integer format, resulting in a number of cents (NNN) represented by the *NNN address signal. In some embodiments, if the exemplary STAR micropayment protocol is defined by a fixed triplet notation (NNN), then the above signal-to-charge conversion in a packet-switched network embodiment may be accomplished by, for example, referencing the SIP URI / To String header and performing string manipulation, such as in the following JavaScript code: parseInt(SIP_To.substring(1,4)).

[0138] In some embodiments, the string operations described above may be combined to extract the leading portion of the address signal listing the charge to be applied, to be forwarded and interpreted internally to the access control platform without parsing any additional (meta)data that may be signaled. In one embodiment, the string function may extract the digits signaled in part-2 of the multi-part signaling schema, i.e., the digits between the first and second star (*) symbols as disclosed herein, to list the charge to be applied. In some embodiments, fees may be collected in any suitable currency and / or cryptocurrency. In some embodiments, transfers of monetary value across the access control platform may be performed using any suitable currency and / or cryptocurrency (e.g., suitable digital tokens and / or coins), while fees charged by the IN may employ real / legal tender / national currency. In some embodiments, following the above notation, a user may dial any amount, e.g., between $0 and $1 (including dialing *000 for audited transactions that incur no expense), although the enumerated common denominations may be sufficient. One advantage of providing a set of discrete values ​​is that it reduces discrepancies recorded and displayed in a phone's dialing history (e.g., a list of recent calls). In some embodiments, the hook flash protocol may enable transactions over the ring and switch funds: From: A PLUS E.164 [+MSISDN] Cellular Sender Wallet ([+A] (or [ A]) Destination: B STAR [*MSISDN] Internet Receiver Wallet [*B].

[0139] In some embodiments, a receiving access control platform wallet is addressed in accordance with the disclosed systems and methods, which in some embodiments utilizes the device registration and / or pairing techniques described above to identify and record the recipient MSISDN for the Internet content provider. In some embodiments, the use of cellular and Internet wallets enables fungible tokenization to transport and convert cellular network access (airtime) into Internet content access (displaytime). In some embodiments, the use of cellular and Internet wallets, facilitated by the disclosed symbolically prefixed signaling and switching advances, successfully transitions the core cellular charging engine, the Authoritative and Irrevocable Cellular Charging Certificate (CDRS), to the cloud. In some embodiments, the CDR certificates (Internet CDR Certificates (ICDRS)) transferred to the cloud retrofit the World Wide Web with microbilling capabilities. [Figure 15C] Figure 15C tabulates and illustrates different address signal encoding schemes in some embodiments. In one circuit-switched network embodiment, address signals are binary-coded decimal (BCD) numbers transmitted in pairs (octets), with each signal represented as a hexadecimal number. ISUP address signals incorporate header information that defines the overall address length, whether the address is composed of even or odd signals, and when odd-length addresses use BCD zeros (0000) as fillers. Such address signals are coded in 4-bit hexadecimal notation, which can represent 16 discrete signals, and considering that the decimal dial digits only require 10 permutations (0-9), as shown in lines 150C to 151C, the remaining 6 characters are written in 10 or more digits, as shown in lines 152C to 157C.

[0140] In telephony BCD notation embodiments, these overdecadic signals may represent the letters "*#ABC" and the stop (ST) signal by their BCD numeric equivalents (decadic). Thus, in telephony BCD encoding embodiments, a star (*) symbol may be encoded as the letter "A," represented by the hexadecimal (binary) number 1010. In natural BCD notation embodiments, these overdecadic signals may similarly represent the letters "ABCDEF," where F indicates a terminating, address complete signal. Thus, in circuit-switched network embodiments, a control or charging element may convert the 4-bit hexadecimal address signal to decimal integer notation and discard any overdecadic signals in order to extract and determine the charge to apply. In some packet-switched network embodiments, address signals are encoded in 8-bit ASCII notation, such as represented by SIP strings in SIP URIs and SIP To headers. Thus, in packet-switched network embodiments, a control or charging element may convert the 8-bit ASCII address signals to decimal (integer) form to extract the enumerated charges. [Figure 16] FIG. 16 presents a flow sequence illustrating the steps of debiting a cellular wallet with the appropriate monetary amount of the address signal and then allowing the Internet micropayment transaction to proceed to completion in accordance with one or more embodiments of the present disclosure. At flow item 1600, the network receives the NNN address signal according to the notation described above in Figures 15A and 15B. The call setup request goes through the OBCSM and AAA (Authentication, Authorization, and Accounting) steps to determine if there is a sufficient credit balance to maintain the appropriate $N.NN charge disclosed to the sending party (originator). At flow item 1610, if the caller has sufficient cellular credit to process the dialed transaction, the flow proceeds along the affirmative YES path to item 1620. If the caller's cellular credit is insufficient to process the dialed transaction, the flow proceeds along the negative (NO) branch to item 1630. At flow item 1620, in determining cellular credit sufficiency, the amount of $N.NN is debited (or subtracted) from the account associated with the originator, here CELL A Wallet[A]. This basic step completes the cellular micropayment component of the Internet transaction and is accomplished by HOOK FLASH (WINK) signaling, as disclosed and described above. At flow item 1630, upon determining insufficient cellular credit, in some embodiments, the network may play an error announcement, for example, "Insufficient credit to complete this call." The network may further instruct the caller to replenish their account or redirect the call to a service platform that accepts payment to replenish the account.

[0141] [Figure 17] FIG. 17 depicts a flowchart schema for setting expectations in an access control platform in accordance with one or more embodiments of the present disclosure. At flow item 1700, the IAPP requests an access control button using a public API that is communicatively coupled to an access control platform to control access to digital content or services at a sticker price of $N.NN. In some embodiments, if the IAPP has previously identified and paired the MSISDN, such identification information is passed to the API via a parameter. In flow item 1701, User A activates the access control button, for example, by tapping or clicking the access control button. At flow item 1702, the access control platform checks whether the IAPP has passed cellular identification information (e.g., registration and / or pairing techniques described above). In some embodiments, if X / MSISDN has not been communicated, flow proceeds along the negative NO branch to step 1703. If X / MSISDN has been communicated, flow proceeds along the positive YES path to step 1704.

[0142] At flow item 1703, the access control platform performs registration and / or pairing techniques to securely determine the cellular ID. In flow item 1704, the access control platform sets the transaction expectation by recording (saving) an [A:NNN] entry in its data store or ledger. This record therefore expects to receive the signal NNN from the telephony device MSISDN-A, matching an activated access control button transaction from a registered and paired telephony device. [Figure 18] FIG. 18 depicts an exemplary flowchart schema for processing a potential access control platform transaction set up according to FIG. 17 above, in accordance with one or more embodiments of the present disclosure. In flow item 1800, activating an access control button may cause the access control button to progress through a series of transitions as described above in Figure 5. In some embodiments, one transition may present a telephone number to dial to conduct an access control platform transaction. In this example, if the access control platform transaction amount presented on the access control button is listed as $N.NN, the button will transition to display a *NNN dialing address in accordance with the disclosed systems and methods.

[0143] In some embodiments, if Internet device A and telephony device MSISDN-A are one and the same device (e.g., a smartphone), the user may tap a button to activate a phone dialer on the telephony device. In some embodiments, when the access control button is tapped, the access control button commands the device to open a default or selected telephone dialer with the *NNN address signal automatically entered. In some embodiments, if telephony device MSISDN-A is distinct from Internet device A, the user may manually enter the *NNN address signal to dial. Once the address signal is entered into the dialer, the user can press CONNECT (e.g., a green telephone button) to place the call. In some embodiments, upon receiving a call setup request that includes an address signal, the cellular network performs AAA (Authentication, Authorization and Accounting) steps. At flow item 1811, accounting validation determines whether the mobile phone wallet or account [A] associated with caller A has sufficient credit ($N.NN per disclosed signal-to-currency direct mapping) to allow the call setup to mature and route to its destination, i.e., continue routing the call to the access control platform. Thus, in some embodiments, access control platform calls may be allowed to route and reach the access control platform only if the caller passes the required credit verification Point in Call (PIC). That is, the mobile phone account [A] associated with the caller is verified to contain sufficient funds necessary to cover the financial match enumerated in the disclosed address signal. Thus, all access control platform transactions are pre-authorized and gated based on established telephony accounting protocols, allowing credit sufficiency to be verified before the call is matured and routed to completion.

[0144] In some embodiments, if the balance of cellular account [A] is less than $NNN, then according to the NNN address signal, the flow branches along the negative NO path to flow step 1813, where, in some embodiments, the network announces an insufficient credit status and terminates the call. In some embodiments, if account [A] has a balance equal to or greater than $N NN signals, the flow proceeds along the affirmative YES path to flow item 1812, where the network is instructed to continue routing and setting up the call along the star path toward the access control platform, as described in more detail below (FIG. 19A). In flow item 1814, upon receiving the call setup request, the access control platform checks whether the expectations for the requested transaction exist and are met; that is, whether a record exists that associates, among other things, the MSISDN-A with the address signal NNN. If such expectations exist and are therefore met, the flow proceeds along the positive YES path to flow item 1815. If such expectations do not exist, the flow branches down the negative NO path to item 1813. In some embodiments, the micropayment expectation, in addition to binding the expected originator MSISDN-A to a set of expected address signals (NNN), further associates and records in the provider access control platform wallet [MSISDN-B] and SKU identifying the content or service controlled by the actively selected access control button having an $N.NN price point. This reverse BA address expectation, established before the user notifies the micropayment, allows the access control platform to bind the originator's Internet device to the content and the content consumer to the content producer, and to process only matching, valid, active, and expected transactions to completion.

[0145] In some embodiments, the expectation is that if a user dials an incorrect price, by dialing a series of decimal digits that do not match the positively displayed SKU price as taught by the methods and systems disclosed herein, and even if the user has sufficient credit to cover the incorrectly dialed transaction, the access control platform may reject the call rather than accept it, thereby not generating a CDR and not executing the incorrect micropayment transaction. In some embodiments, matching incoming access control platform calls to the described expectations allows for technical improvements including counter-binding for both providers and consumers, as well as preventing erroneous transactions from being performed against the caller's account, since transactions are not performed if they are not expected (expected). In some embodiments, once the expectation is met, the access control platform instructs the network to play an RBT to the caller (not shown), which provides an audio confirmation that the transaction has been greenlit.

[0146] In flow item 1815, the access control platform executes a telephony hook flash, a short OFF HOOK signaling event, and takes the call OFF HOOK to initiate transaction recording. At flow item 1816, the access control platform pauses, for example, for 500 milliseconds to 1 second, in some embodiments, to generate at least 1 second of talk time. In flow item 1817, the access control platform returns a callback on hook to complete the CDR recording. At flow item 1818, upon successful completion of the hook flash signaling protocol as described in Figure 3 above, the network records a CDR for the transaction that debits Cellular Account [A] with the transaction amount of $N.NN signals, thereby completing the cellular component of the transaction. In flow item 1819, upon receiving confirmation that the network successfully disconnected the call, the access control platform, following the disclosed hookflash protocol, updates the access control platform ledger to reflect the successful payment, credits the Internet access control platform system[*] and provider[MSISDN-B] wallets, and communicates the completion of the transaction to the access control button. If the transaction communication is successful, the access control button transitions to a completed state (check mark), access to the purchased digital content or content and / or services is unlocked, and the user can navigate to the content and / or services via the IAPP and / or web browser.

[0147] [Figure 19A] FIG. 19A is a control scheme corresponding to the flow methodology presented in FIG. 3 and shows in more detail the sequential signaling step ladder for the disclosed micropayment system and method in accordance with one or more embodiments of the present disclosure. Flow item 1900 、 In access control element 1945, internet device 1948 requests access to digital content in the cloud (1901) that requires payment and is therefore lock-protected as shown. The content creator utilizes an appropriate API to render an access control button (1902) on the display of internet-enabled device 1948, requesting payment at the stated sticker price ($N.NN). In this example, it is assumed that the content provider has previously registered the associated MSISDN (B) as a provider ID, for example, using the registration and / or pairing techniques described above. Upon requesting an access control button 1902, the access control button API communicatively couples to an access control element (1945) and includes parameters describing the characteristics of the access control button 1902, including, but not limited to, in some embodiments, dollar amount, provider ID, SKU, button style, redirect URL upon payment completion, etc. In this schematic, it is assumed that a browser presenting IAPP or Internet hosted content / services is registered and paired with the cellular identity MSISDN-A of user telephony device A (1940), as described above. In some embodiments, the pairing logically binds the amount of access control platform presented on access control button 1902, as displayed on internet device 1948, with the registered cellular identity MSISDN-A, uniquely binding and staging pending transactions.

[0148] Thus, upon receiving the access control button 1902 metadata via the API, at flow item 1910 in access control element 1945, the access control element (1945) then sets (records) the payment expectation [A:NNN] via the access control ledger 1946, as described above in Figure 3. While the schema depicts the access control button 1902 communicating directly with the access control element 1945, other access control platform elements may be involved and traversed in this communication. Thus, the access control button 1902 REQUEST results in the access control platform EXPECTATION being SET. While the request for the access control button 1902 itself may precipitate this expectation, given that multiple access control buttons 1902 may actually be displayed, that expectation may be deferred to button activation (selection). A user may select multiple micro-payment items for purchase and create a cumulative payment total (the sum of all selected items), but with such multiple payment methods, the expectation may be deferred to record the expected total for the pending transaction. The disclosed methods and systems governing button presentation and state management are described in more detail above in FIG. 5, which illustrates a button transition series in some embodiments.

[0149] In flow item 1910, mobile device A 1940 dials the access control platform signal *NNN to send a mobile-originated (MO) call to a service switching element (e.g., MSC) 1941. The setup message includes the *NNN address signal in addition to other call parameters. The MSC enters the OBCSM and detects the INITDP. In flow item 1920, INITDP establishes a call control dialog between the MSC 1941 and a prepaid service control point (SCP) 1942, the address of which, in some embodiments, is recorded in the SIM Originating Camel Subscription Information (O-CSI) of the MSC / VLR 1941. Customized Applications for Mobile Networks Enhanced Logic (CAMEL) configurations may employ standards that operate over a Global Systems for Mobile Communications (GSM) core network or a Universal Mobile Communications System (UMTS) network. In a CAMEL O-CSI embodiment, the MSC 1941 has an associated gsmSSF (GSM Service Switching Function) and the SCP 1942 is referred to as the gsmSCF (GSM Service Control Function). SCP 1942 is configured to perform credit verification of User A by determining whether the account associated with device 1940 has sufficient credit to complete the call (i.e., a positive balance of $N.NN or more in this example) by, for example, querying an online charging system (OCS) 1943, or a prepaid charging system. Although SCP 1942 and OCS 1943 are depicted as separate elements, they may be one and the same logical or physical element, incorporating additional charging elements and embodying control logic for both calling and charging. In flow item 1930, in response to the credit verification check, OCS 1943 may respond to SCP 1942 that the account associated with device 1940 has sufficient credit to complete the call. Depending on the sufficiency of credit, the SCP instructs MSC 1941 to proceed with the call. It is important to note that although figures in some embodiments herein may show control and / or charging elements issuing a CONTINUE command and instructing switching elements to continue routing and allow the call to proceed as originally signaled, in some networking embodiments the control or charging element may modify the symbolically prefixed address signal and then issue a CONTINUE with the modified argument instruction.

[0150] For example, in a telephony BCD encoding scheme such as that described above in FIG. 15C, a star-prefixed address signal (e.g., *010) may be encoded and received by a network switching element as "A010." In some embodiments, the control and / or switching element may then convert the symbolic overdecadic signal (i.e., the "*" address signaling prefix encoded as "A") and replace it with an internal short routing prefix RRR (e.g., 555) that defines a routing path to an access control element (e.g., a Star Access Control Platform). The short routing prefix typically consists of three or four characters and may itself contain hexadecimal characters (e.g., 555A). If the control element or charging element translates and modifies the original address signal originated by the cellular device, it then issues a CONTINUE with the modified argument instruction (i.e., the modified CgPN address, e.g., 555010), thereby instructing the switching element to perform a route lookup with the new internal routing prefix to determine the network routing path to the access control element. In flow item 1940, in one symbol-prefixed signaling embodiment, the MSC 1941 performs a routing lookup on the star prefix in the address signal to determine a trunk / route to an access control element 1945, which may be cloud-hosted, and sends an ISUP IAM (Initial Address Message) to the GMSC / SBC 1944, which establishes a mobile-originated (MO) leg 1999.

[0151] The GMSC / SBC 1944 (or media gateway controller) is configured to interwork between Signaling System 7 (SS7) and IP networks, and in some embodiments, is configured to perform signaling conversion between ISUP and SIP (Session Initiation Protocol). In the ISUP / SIP conversion, the ISUP IAM is converted to a SIP INVITE, which is sent to the access control element 1945. ISUP includes messaging protocols such as IAM and is the part of SS7 used to set up telephone calls in the Public Switched Telephone Network (PSTN). The Mobile Application Part (MAP) can be used as an SS7 protocol for setting up and controlling calls over the PSTN by providing an application layer for GSM and UMTS mobile core networks and the General Packet Radio Service (GPRS) core network for communications and services between mobile users. Telephone exchanges (such as switches) may be connected via T1 or E1 trunks as a shared communication circuit path for carrying voice from calls. SIP is a signaling protocol for initiating, maintaining, and terminating real-time multimedia (voice, video, messaging, etc.) sessions for Internet telephony applications and / or instant messaging over Internet Protocol (IP) networks and / or Voice over IP (VOIP) networks. In flow item 1940, upon receiving the SIP INVITE, the access control element 1945 queries the access control ledger (1946) to determine whether an access control platform transaction for the device MSISDN-A (1940) emitting the NNN address signal is expected (configured) and currently matched (fulfilled).

[0152] In flow item 1950, upon matching the expected transaction in this manner, in some embodiments, the access control element (1945) optionally responds with a SIP 180 / RINGING message in the reverse direction, as indicated by the parentheses, instructing the GMSC / SBC 1944 to return an ISUP Address Complete Message / Call Progress (ACM / CPG) Alert message and notifying the MSC 1941 that the transaction has connected to the access control platform. The MSC 1941 may then present an RBT to the mobile device 1940, as graphically indicated (BELL). In responding with the SIP 180 / RINGING message, the access control element 1945 matures the call into an originated, completed call, marking the call setup as successful. The SIP / 180 response is optional as it does not significantly impact the access control platform protocol, which relies on the disclosed WINK signaling (hook flash) signaling to carry out the transaction as described below, and further, the access control platform user experience is visually communicated via the access control button 1902 within the IAPP as disclosed. In flow item 1960, the access control element 1945 then instructs the GMSC / SBC 1944 to answer the call by issuing a SIP 200 / OK message (CSEQ:INVITE) in the reverse direction, which is then converted to an ISUP ANS (ANSWER) message at the GMSC / SBC 1944. 、The MSC 1941 is notified that the call has been answered. At this point, the call is answered as shown textually at flow step 1960 and graphically at 1961. <1> ), and the call duration timer for CDR generation associated with the answered call is started. At flow item 1970, the access control element 1945 then disconnects the call by issuing a SIP BYE command in the opposite direction, in some embodiments between 500 milliseconds and 1 second later (or any other suitable period), which the GMSC / SBC 1944 converts to an ISUP REL (Release) and instructs the MSC 1941 to release the call, placing the call in the ON HOOK state (DISCONNECT BINARY STATUS) as shown textually in the flow step. <0> ) back to 1970 and 1971 graphically.

[0153] This star mobile hook flash signaling is therefore directed by the access control element 1945 to lift (i.e., respond) the receiver to OFF HOOK, and then, in some embodiments, for 500 milliseconds to 1 second thereafter (or any other suitable time period), return (i.e., release) the receiver to ON HOOK. Flow item 1980 successfully disconnects the call on the network and the MSC 1941 responds with a forward ISUP RLC (Release Complete), which is converted in the GMSC / SBC 1944 to a SIP 200 message that is sent to the access control element 1945, which completes the STAR RING HOOK FLASH, or STAR HOOK FLASH (no RBT presentation) payment protocol (block 1991). In flow item 1990, upon issuing the ISUP RLC, the MSC 1941 completes the CDR generation, thus recording a nominal call duration event (e.g., 1 second), and thereby debits the account associated with the caller NNN¢ (cents) per the disclosed micropayment method. In some embodiments, such mobile origination dialogue, collectively referred to herein as the "ring hook flash" (or "hook flash") signaling protocol (block 1991), presents caller A with an instant ring tone, followed by momentary call connects and disconnects (OFF / ON HOOK), thus raising and dropping the call to present a call duration of 00:00:01 seconds on the display of device A 1940. This hook flash signaling protocol and clearing provides audiovisual confirmation that the transaction has been successfully completed.

[0154] Upon receiving the SIP 200 at flow item 1980 in response to the SIP BYE message issued by access control element 1945 at flow item 1970, the network acknowledges that the hook flash transaction is complete and the CDR is recorded. This acknowledgement acknowledges that the account associated with device 1940 is debited with the $N.NN micropayment, confirming the successful completion of the cellular portion of the transaction. If the device 1940 disconnects the call before the completion of hook flash signaling, either in response to the user pressing disconnect (e.g., pressing the red phone button) or because the network drops the call (e.g., signal loss or network congestion), the transaction is not completed. In such a scenario, in some embodiments, the access control element 1945 communicates the failure of the transaction to the access control platform button 1902 / 1982, which may then change state to reflect a "CANCEL" event (not shown) that has occurred. In flow item 1980, in response to the successful completion of the cellular transaction, the access control element 1945 updates LEDGER 1946 to record the successful completion of the micropayment transaction and credits the access control platform's own wallet (system wallet) [*] with the corresponding amount of $N.NN and the provider's access control platform wallet [*B] with the transaction amount ($N.NN) minus any switching and processing fees that may be applicable (neither shown).

[0155] In flow item 1981, the access control element 1945 then communicates a successful RESPONSE to the access control platform button 1902. In some embodiments, a successful RESPONSE causes the access control button 1902 to change its state to reflect PAID (1982), resulting in For access by device 1948 Unlock digital content and / or services (1983). While the RBT and hook are flashing, the primary access control platform user experience may provide telephony audiovisual feedback present within the access control platform buttons as they transition under STAR1945 signaling, state management and control, as described above in FIG. 5. [Figure 19B] 19B is a control scheme corresponding to the flow methodology presented in FIG. 3, illustrating in more detail the sequential signaling step ladder for the disclosed micropayment system and method for outgoing VoLTE call requests in accordance with one or more embodiments of the present disclosure. FIG. 19B shares corresponding labels and steps with FIG. 19A, except for those flow items annotated with the letter B, whereas FIG. 19A describes a circuit-switched framework and associated mobile phone device 1940, whereas FIG. 19B 、 VOLTE telephony device, User Equipment (UE) accessing packet switched networks 1941B / 1942B 1940BThis control schema describes native SIP signaling capabilities between the UE 1940B, the IMS network elements 1941B and 1942B, and the access control platform 2.

[0156] In some embodiments, the communications network may be a packet-switched network that supports Session Initiation Protocol (SIP) user equipment (UE). The packet-switched network may be IMS, VoLTE, a combination thereof, or other suitable packet-switched network that moves data in separate data packets based on a destination address to transmit a message. SIP is a signaling protocol for initiating, maintaining, and terminating real-time multimedia (voice, video, messaging, etc.) sessions for Internet telephony applications and / or instant messaging over Internet Protocol (IP) networks and / or Voice over IP (VOIP) networks. UEs may include smart or otherwise network-connected devices, such as the first user mobile device described herein. The embodiments described herein may be based on packet-switched networks and / or may be integrated with circuit-switched networks based on dedicated point-to-point connections for calls, as described in more detail below. Packet-switched networks group data so that it can be transmitted as packets (e.g., individual blocks of data) over a digital network. As mentioned above, one such packet-switched network may be Voice over Long Term Evolution (VoLTE), which utilizes the Internet Multimedia Subsystem (IMS) and packet-switched voice services, as IMS VoLTE, which is high-speed wireless communication for cellular devices and data terminals, such as other smart mobile devices that may be on Internet of Things (IoT) networks. IMS VoLTE includes VoLTE as a high-speed wireless communication protocol and utilizes IMS to implement standards and procedures for delivering voice communications and data over 4G LTE networks. Data from circuit-switched cellular networks (i.e., Code Division Multiple Access (CDMA) and Global System for Mobile Communications (GSM)) may be converted into network packets before being broadcast over public switched networks such as IMS VoLTE. VoLTE uses an IMS-based network to deliver these services. VoLTE supports rich multimedia communications, including high-definition audio and video services, operating over 4G and LTE data-enabled networks. The IMS may reside as a standalone system outside the VoLTE network and be connected to the VoLTE network via a communication coupling via an interface to a gateway of the VoLTE network, such as the SGi interface connecting the IMS with a public data network (PDN) gateway, as described in more detail below. One or more UEs may be communicatively coupled via interfaces to the Evolved University Mobile Communications System Terrestrial Radio Access Network (E-UTRAN) and the Evolved Packet Core (EPC) of the VoLTE network, as well as interfaces to the IMS network and IP services such as the Internet. The E-UTRAN is the radio access network that serves as the air interface for the 3rd Generation Partnership Project (3GPP) LTE IN upgrade path.

[0157] The EPC of a VoLTE network may include functional elements such as the Mobile Management Entity (MME), Serving Gateway (S-GW), and PDN Gateway (P-GW). The MME is the control point responsible for most control plane functions. The S-GW processes IP packets for uplink and downlink transmission and handles handovers. The PDN Gateway assigns IP addresses to UEs and serves as the communication point between EUTRA and other non-3GPP services such as the Internet. Each PDN Gateway may provide associated interfaces to the IMS and the Internet, such as the SGi interface, which is the reference point between the PDN Gateway and the packet data network. The EPC may further include a Policy and Charging Rule Function (PCRF) element as a functional element for determining allowed traffic types in real time and traffic accounting for charging purposes. When a UE initiates a VoLTE call, the PCRF checks whether the UE has a subscription to initiate the call and, if so, may set up a dedicated bearer for IMS services. An IMS-powered UE may include a Universal Integrated Circuit Card (UICC) and a Session Initiation Protocol User Agent (SIP UA) to send and receive SIP messages and provide telephony functions. The UICC may include identity modules such as a Subscriber Identity Module (SIM) and an IP Multimedia Services Identity Module (ISIM) used by the IMS subsystem.

[0158] Numerous elements may comprise an IMS / VoLTE packet-switched network. However, for simplicity, IMS / VoLTE may be referred to herein as a generalized SIP network subsystem. Furthermore, while the key functional elements of the VoLTE architecture as described herein may be defined by 3GPP, it also allows non-3GPP technologies to interface with and be managed from an IMS VoLTE network. IMS functional elements in IMS Core that manage call setup and control may include a Proxy Call Session Control Function (P-CSCF) and a Serving Call Session Control Function (S-CSCF). The P-CSCF may be the first point of contact for session signaling for an IMS-enabled VoLTE user equipment (UE). The P-CSCF may act as a SIP proxy by forwarding SIP messages between the UE and the IMS core network. The S-CSCF contains data about user knowledge and application permissions associated with a user account. The S-CSCF in IMS Core provides session, routing, and charging functions for all sessions under its control and can invoke application servers based on the Initial Filter Criteria (IFC) received from the Home Subscriber Server (HSS) during service registration. The S-CSCF can act as a SIP registrar for VoLTE user equipment (UE) for user accounts assigned by the HSS and Interrogating Call Session Control Function (I-CSCF). The S-CSCF can query the HSS for subscriber profiles used to authorize and manage requested services.

[0159] The S-CSCF may therefore be a central element in the IMS signaling plane. The S-CSCF may also be a SIP server that performs session control and, in some embodiments, downloads and uploads user profiles associated with user accounts to the HSS using the Diameter Cx and Dx interfaces. The S-CSCF handles SIP registrations and may also be included in the signaling path for all messages. In at least some embodiments, the S-CSCF may determine the application server (AS) to which SIP messages from the UE's SIP UA, processed by the P-CSCF, should be forwarded for service provision and provide the necessary routing. The S-CSCF can therefore enable the allocation of an AS to a session as needed. In some embodiments, the role of the S-CSCF is to fulfill the session request by locating the destination endpoint and signaling it. The S-CSCF can also play media announcements / tones to the originator in coordination with the Media Resource Function (MRF). According to 3GPP technical specifications, the S-CSCF also functions as a Charging Trigger Function (CTF), which manages the charging of users of the IMS infrastructure and services. The S-CSCF communicates with an IMS Gateway Function (IMS-GWF), which acts as a SIP application server, and can signal the S-CSCF to terminate a session when a user runs out of credits during the session. While the S-CSCF functions as a CTF, the same functionality can be applied to any IMS network element. In an embodiment, as a CTF element in an IMS network, the S-CSCF may perform several tasks corresponding to and triggered by user session activity to identify the correct charging to apply. When performing normal routing operations on SIP signaling, the S-CSCF may determine whether the SIP information represents chargeable activity and what type of charging mechanism may apply. The charging mechanism for IMS sessions can be either offline (postpaid) charging using accounting messages or online (prepaid) charging using substantially real-time credit control messages and procedures. Information about IMS transactions can be sent from the S-CSCF to a charging element, which collects and stores this information in the form of charging data records (CDRs).

[0160] At flow item 1910B, user A, via VoLTE UE device 1940B, dials address signal *NNN, representing microtransaction $NNN, in accordance with the disclosed method and system. As a result of the dialing, UE 1940B sends a SIP INVITE request to P-CSCF 1941B, whose address is discovered during the UE registration procedure (not shown). The INVITE request may include an IMS Communication Service Identifier (ICSI) for IMS Multimedia Telephony (e.g., urn:urn-7:3gpp-service.ims.icsi.mmtel) in the Contact and P-Preferred-Service headers. In flow item 1920B, the P-CSCF 1941B adds a P-Charging-Vector header and forwards the SIP INVITE to the S-CSCF 1942B (not shown) identified during UE registration. The S-CSCF 1942B receives the SIP INVITE from the P-CSCF 1941B. 。The S-CSCF 1942B invokes VoLTE services defined and triggered by the Initial Filter Criteria (IFC) in the subscriber profile obtained during IMS registration. The S-CSCF 1942B verifies that the user is authorized for the service by checking the P-Preferred-Service header in the SIP INVITE request (e.g., MMTel ICSI) and validating it against the subscribed services obtained in the service profile during registration. For example, in online charging, the OCS may authorize the use of network resources based on the price or fee of the requested service and the subscriber's account balance. The OCS may support at least two types of online charging functions: session-based charging (SBCF) and event-based charging (EBCF). The SBCF may be responsible for network bearer and session-based services such as voice calls, GPRS sessions, and IMS sessions. It may also be able to control sessions by allowing or denying session establishment requests after verifying the subscriber account. In the OCS, a rating function (RF) may determine the price / fee for the requested network resource usage in real time.

[0161] At flow item 1920B, the P-CSCF 1941B may respond to the requesting UE 1940B with a SIP 100 TRYING to prevent an INVITE timeout. The P-CSCF 1941B may then forward the INVITE to the S-CSCF 1942B, which may then send an initial credit charge request (e.g., CCR CC-request-type "INITIAL_REQUEST") to the OCS 1943. The OCS 1943 may collectively comprise a session balance control function (SBCF) and an account balance management function (ABMF). In flow item 1920B, upon receiving the CCR message, the SBCF may obtain account information and a subscriber profile from the OCS ABMF. The SBCF can then send a Tariff Request message to the RF to determine the tariff for the IMS call. Based on the subscriber information, the RF may respond to the SBCF with a Tariff Response message that includes the billing plan and tariff information for the IMS service. Upon receiving the tariff information, the SBCF can make a credit unit reservation with the ABMF. It may then respond to the S-CSCF 1942B with a Credit Control Answer (CCA) message containing the granted credit (e.g., specifying the number of seconds or minutes allowed for the call). If it is determined that the account associated with user A has sufficient credit (in this embodiment, $N.NN or more credit), the CCA message returned at flow item 1930B may indicate successful credit approval. In some embodiments, in flow item 1930B, in response to receiving CCA Success, the S-CSCF 1942B or attendant TAS may then reroute the INVITE request via the SBC 1944 using modified call signaling (e.g., *NNN@) to the IP address of the access control platform 1945 as the transaction processing platform.

[0162] In flow item 1940B as shown, in response to receiving CCA Success, the S-CSCF 1942B or attendant TAS may create a new call leg for the modified INVITE request, thus including the modified address, identification service code prefix, and modified call signal with the destination address of the signaling switch. In embodiments, the modified address incorporates an identification service code (e.g., :* or XXX) prefixed to the B address signal and specifies the star domain in the branched URI as the network identifier for the micropayment access control platform's destination address. As a non-limiting example, the modified address may be in the following format: SIP / 2.0 sip:*NNN@starlogik.com Invite or INVITESIP:555NNN@55.225.225.45 SIP / 2.0, where 555 is the prefix of the applied service code and 55.225.225.45 is the IP address (in IPV4 notation) of the Star Access Control Platform. The S-CSCF 1942B then adds a Via header with the new fork tag, which in some embodiments allows the call to be forked (transferred or sequentially forked) to the access control platform 1945 via the SBC 1944. Symbol prefix URLs can further incorporate the Mobile Network Code (MNC) and Mobile Country Code (MCC) assigned to a Mobile Network Operator (MNO). SIP / 2.0 sip:*NNN@7.655.starlogik.com Invite. The example INVITE above shows the DNS URL for MNO Cell C in South Africa (MCC=655 is the country designation for South Africa, and MNC=7 is the MNO's network identifier). The MNC Level 4 and MCC Level 3 domains allow dynamic DNS resolution to country and carrier by Fully Qualified Domain Name (FQDN) for localized access control platform hosting.

[0163] In accordance with the call data record generation coordination disclosed herein, the originating CDRS of the hook flash communication method (Ring Commerce Uplink, block 1991) may, in some embodiments, generate CDRs recorded with MSISDN-A and address signal *NNN (A*NNN Title CDRs). As described above, branching the INVITE request with the modified NNN address signal maintains CDR coordination with the executed micropayment transaction. This NNN address signal modification can ensure that the originating S-CSCF CDR generated when the access control element 1945 performs the hook flash method as described above in FIG. 19A. In flow item 1960B, the STAR 1945 goes OFF HOOK (picks up the call) and then, for example, for 500 milliseconds to 1 second or other period, for the nominal call length, and then, in flow item 1970B, returns to ON HOOK (disconnects the call), is distinguishable as a CDRS entitled A*NNN (or XXXNNN). Such A*NNN-generated CDRs (e.g., Star CDR data sets) may be audited to calculate cumulative access control platform transactions performed over a period of time.

[0164] Thus, flow items 1940B-1980B communicating with the access control platform 1945 are functionally equivalent to flow items 1940-1980 of FIG. 19A; however, because the described IMS / VOLTE packet-switched network may utilize SIP signaling, signaling protocol conversion between the UE 1940B, the IMS network elements (P-SCSF 1941B and S-SCSF 1942B), and the access control platform 1945 may not be required in this embodiment.

[0165] [Figure 19C] Figure 19B is a control scheme corresponding to the flow methodology presented in Figure 3 and illustrates in more detail the sequential signaling step ladder for the disclosed micropayment system and method according to one or more embodiments of the present disclosure. Figure 19C is similar to Figure 19A in that it shares corresponding labels and steps with Figure 19A, except for those flow items annotated with the letter C. While Figure 19A depicts cell phone 1940 in flow item 1910 emitting the signal *NNN, Figure 19C illustrates an embodiment in which cell phone 1940 signals NNN in flow item 1910C, without the symbolic prefix. In flow item 1930C 、 The SCP 1942, in some embodiments with an associated OCS 1943, automatically modifies received NNN address signals to include a routing prefix that identifies the access control platform 1945, if those signals contain between a minimum and maximum of three digits and a maximum of five digits. In flow item 1930C, upon modifying the NNN address signal in this manner, SCP 1942 instructs MSC 1941 to CONNECT the call with the now-modified address signal, e.g., *NNN. This may instruct MSC 1941 to reroute the call in flow item 1940 along a SIP trunk via both a gateway MSC (GMSC) or media gateway controller (MGC), and in some embodiments, via SBC 1944 to access control platform 1945. The MGC / SBC may perform the conversion from ISUP IAM to SIP INVITE signaling protocol as disclosed herein.

[0166] At flow item 1930C, the MSC 1941 may look up a pre-configured routing table that includes a trunk indicator (e.g., trunk communication path) associated with the modified address signal prefix and translate / route the modified address from the pre-configured routing table based on the trunk indicator of the trunk associated with the modified address. The modified call signal may be automatically routed along the trunk from the MSC 1941 to the GMSC / MGC or SBC 1944, and then automatically routed along the SIP trunk to the access control platform 1945. The disclosed micropayment transaction then proceeds according to FIG. 15A as described above.

[0167] [Figure 20] 20 illustrates an illustrative, non-limiting example of a process based at least in part on mobile communication signals in accordance with at least some embodiments of the present disclosure. In some embodiments, the process includes an access control platform 2000, implemented, for example, as a cloud platform, interfacing with a cellular network 2030 to conduct transactions using CDRs. In some embodiments, mobile phone 2020 may be associated with a cellular network 2030 and a network account (wallet, not shown). In some embodiments, telephony device 120 may communicate with cellular network 2030 to transfer value from the network account to access control platform 2000 for access to digital goods and / or services 2040 for delivery to telephony device 2020. In some embodiments, telephony device 2020 communicates a request for a transfer of value by formatting address signals in a telephone call to carry the value to be transferred. In some embodiments, the access control platform 2000 is configured to interface with a cellular network 2030. Thus, the cellular network 2030 may provide value for depositing virtual tokens from an account of the telephony device 2020 to an access control platform wallet 2010 associated with a provider of digital goods and / or services 2040. In some embodiments, the virtual tokens may comprise authentic, transparent, and low-cost fiat-backed microcurrency. By providing the virtual tokens to the provider's access control platform wallet 2010, the access control platform 2000 can provide value for the digital goods and / or services 2040 so that the digital goods and / or services 2040 can be distributed to the telephony device 2020. As a result, adaptation to the cellular network 2030 can democratize internet commerce and access to digital content and / or services.

[0168] Those skilled in the art of switching and billing will understand that alternative embodiments can include, without limitation, those incorporating metadata along with the dialed digits that list the appropriate amount, where such metadata can include data identifying the beneficiary and stock keeping unit (SKU). Some embodiments may include the use of a hook flash protocol, where the telephone call is temporarily turned off to carry out the transaction and then returned on-hook, and the address signal recites the transaction amount, although other network protocols and bearers may be employed that provide suitable transaction functionality, including but not limited to USSD and SMS bearers. In an alternative USSD embodiment, the following mobile originating dialing string may achieve a similar result: *NNN# or *XXX*NNN# . The USSD example above could similarly be interpreted as requesting a transaction with a monetary appropriate $N.NN that matches the signal NNN, and the XXX code could identify a USSD application that provides a typical transaction within a USSD service offering. The USSD command string in some embodiments uses a star as a delimiter to separate variables. For example, the following USSD dial string can be constructed to encapsulate the alternative micropayment application XXX, the monetary appropriate amount NNN, the provider identifier PPP, and the product SKU CCC being purchased: *XXX*NNN*PPP*CCC# . In the USSD example above, PPP and CCC are the number or digits required to uniquely identify the provider and the item being sold. Similarly, NNN is the number of digits required to enumerate the appropriate monetary amount, with more digits representing higher cost items. In another USSD embodiment, the USSD string may encapsulate (embed) a multi-part address signal as disclosed herein. In yet another USSD embodiment, the micropayment application may be identified by leading zeros as follows: *0NN# is converted to $0.NN *0NNN# is converted to $N.NN. In some embodiments, a zero-based (prefixed) USSD command string embodiment can condense the USSD application identifier to a single identification and leading digit (zero), in some embodiments three digits, to present a reduced USSD instruction set that enumerates transaction amounts in accordance with the telephony embodiments described herein. The hosting, routing, and / or execution of USSD applications may be serviced internally by the network using protocols such as Mobile Application Part (MAP) signaling, or externally using an external messaging entity connecting to the carrier USSD and / or SMSC messaging platform using standard Internet protocols such as SMPP or HTTP. In one SMS micropayment embodiment, the systems and methods disclosed herein may also be implemented by allowing a user, and by proxy their mobile device, to send payment instructions to an SMS short address code that itself lists the transaction amount. The SMS signaling path and billing process in the Intelligent Network (IN) can be similar to that of the disclosed symbolically prefixed telephony protocol. By modifying the SMS routing (e.g., message interception and CdPA-based routing) and modifying the billing system in accordance with the telephony system and method described above, all such symbolically addressed mobile-originated messages can be utilized for the disclosed cellular micro-billing, i.e., debiting an account associated with the sending mobile device by the amount listed in the SMS address, and then routed over the symbolic address prefix to an access control platform (e.g., the DCB platform of the present disclosure) to complete the Internet transaction. For example, allow SMS to: *This is NNN.

[0169] Because many mobile devices allow SMS to be sent in the background of an IAPP, under programmatic control, and without user intervention, such symbol-prefixed SMS signaling services offer a similarly engaging and frictionless user experience. Additionally, SMS sent by users lacking sufficient credit may be immediately rejected (e.g., if the operator returns a MO_FSM_Neg_Response), alerting the device to the failed transmission and preventing access to the content, preserving the interactive, real-time signaling characteristics exhibited during the transaction, as disclosed using telephony protocols. As detailed above, premium rate SMS services have historically been unable to transparently reflect applicable fees because PSMS short address codes do not encapsulate or display the cost of the service. Additionally, many PSMS services require separate short codes to charge different amounts. By allowing consumers to utilize symbol-prefixed SMS signaling services to transact as disclosed herein, PSMS platforms can be modified to overcome such billing and marketing limitations by accepting universal signaling, which encapsulates the cost of the service (applicable charges) in a symbolically addressed, mobile-originated SMS header. While existing PSMS platforms utilize two-way, mobile-terminated SMS, which consumes significant network resources (i.e., paging and identifying the destination device and forwarding a return confirmation), the newly disclosed mobile-originated SMS transaction can be performed in one step and does not necessarily require SMS confirmation content in the message body. Originating a message instructs the operator to apply a signaling charge. Short messages sent without a content payload reduce the signaling load on the network. Furthermore, such a cellular messaging signaling system would satisfy the data requirements that constitute a "card present" transaction, as described above, since a mobile-originated SMS addressed in this manner would generate an authoritative and irrevocable billing record that captures the transaction data and cost at the time of transmission. For example, sending a mobile-originated STAR SMS can result in the CDRs shown in Table 4. [Table 4]

[0170] In some embodiments, making a payment over the Internet requires the user to log in to the exemplary access control platform of the present disclosure, for example, by entering a registered username and password, and often a two-factor code (2FA) to authorize the transaction. Thus, improvements to online payment processing are enabled by the disclosed embodiments by leveraging existing biometric and other protection measures used to lock mobile phones, thereby preventing unauthorized access to the phone and, therefore, to the micropayment functionality, without relying on vulnerable network communications for authentication. Because the disclosed methods and systems require access to communication services on a computing device (e.g., a mobile phone, a cellular service-enabled computer (e.g., laptop, tablet, etc.), these existing device protection measures eliminate the need for additional payment security features, such as a secret PIN, since the device is already protected from unauthorized access. Reducing the number of steps required to effect a micropayment not only improves the user experience, but may also lead to higher frequency of use. In some embodiments, the exemplary inventive computer-based system / platform, exemplary inventive computer-based device, and / or exemplary inventive computer-based component of the present disclosure may be configured to support a network of at least 100 users (e.g., without limitation, 100-999 users), at least 1,000 users (e.g., without limitation, 1,000-9,999 users), at least 10,000 users (e.g., without limitation, 1,000-9,999 users), or at least 10,000 users (e.g., without limitation, 1,000-9,999 users). , including but not limited to, 10,000-99,999), at least 100,000 (for example, but not limited to, 100,000-999,999), at least 1,000,000 (for example, but not limited to, 1,000,000-9,999,999), at least 10,000,000 (for example, but not limited to, 10,000,000-999,999,999), at least 100,000,000 (for example, but not limited to, 100,000,000-999,999,999), at least 1,000,000,000 (for example, but not limited to, 1,000,000,000-10,000,000,000).

[0171] [Figure 21] 21 illustrates an exemplary, non-limiting process illustration based at least in part on mobile communication signals in accordance with at least some embodiments of the present disclosure. In some embodiments, the exemplary process of FIG. 21 includes, in step 2101, receiving, by a processor of a computing device, via an application program and a communications network, at least one application program instruction for displaying an access controller interface element and an access code on a screen of the computing device, wherein the access controller interface element is communicatively coupled to a cellular network-hosted access control scheme and operatively linked to an access-restricted digital resource.In step 2102, executing the at least one application program instruction by the processor of the computing device to display the access controller interface element and the access code on a screen of the computing device; in step 2103, detecting at least one activity associated with the access controller interface element by the processor of the computing device; in step 2104, transmitting by the processor of the computing device, based on the detection of the at least one activity, an access request having data including an access code and an ID linked to the computing device, wherein at least one portion of the data is configured to be accepted by a cellular network-hosted access control schema; in step 2105, receiving by the processor of the computing device, via the application program, at least one access program instruction for unlocking an access-restricted digital resource for access via the computing device, wherein the reception of the at least one access program instruction for unlocking the access-restricted digital resource occurs after at least one portion of the data has been accepted by the cellular network-hosted access control schema; Then, in step 2106, execute, by a processor of the computing device, at least one access program instruction for unlocking the access-restricted digital resource for access via the computing device.

[0172] [Figure 22] 22 illustrates an exemplary, non-limiting process based at least in part on mobile communication signals according to at least some embodiments of the present disclosure. In some embodiments, the exemplary process of FIG. 22 includes, in step 2201, transmitting, by a processor of an access control server, via an application program and a communications network, to a computing device, at least one application program instruction for displaying an access controller interface element and an access code on a screen of the computing device; in step 2201, the access controller interface element is communicatively coupled to a cellular network-hosted access control scheme and operatively linked to an access-restricted digital resource for which access via the computing device is restricted; and in step 2202, receiving, by the processor of the access control server, an access request based on at least one activity associated with the access controller interface element, wherein the access request has data including: the access code and an identity linked to the computing device; in step 2203, by the processor of the access control server, querying the cellular network hosted access control schema for a positive access permission indication based on at least one portion of the data, wherein at least one portion of the data is configured to be accepted by the cellular network hosted access control schema; and in step 2204, by the processor of the access control server, sending to the computing device, via the application program, at least one access program instruction that unlocks an access-restricted digital resource for access via the computing device based on the positive access permission indication;

[0173] [Figure 23] 23 illustrates an exemplary, non-limiting process based at least in part on mobile communication signals according to at least some embodiments of the present disclosure. In some embodiments, the exemplary process of FIG. 23 includes, in step 2301, transmitting, by a processor of an access control server, via an application program and a communications network, to a cellular device, at least one application program instruction for displaying an access controller interface element and an access code on a screen of the cellular device; wherein the access controller interface element is communicatively coupled to a cellular network-hosted access control schema and operatively linked to an access-restricted digital resource to which access via the cellular device is restricted; and, in step 2302, receiving, by the processor of the access control server, from the cellular device, an access request based on at least one activity associated with the access controller interface element; wherein the access request has data including: the access code and a cellular ID linked to the cellular device; in step 2303, a positive access permission indication by the access control server from the cellular network hosted access control schema in response to receiving, processing and accepting a series of mobile originating address signals (at least a portion of the data) as disclosed herein emanating from the cellular device associated with the cellular ID; and in step 2304, by the access control server processor, based on the positive access permission indication, transmitting to the cellular device via the application program at least one access program instruction for unlocking an access-restricted digital resource for access via the cellular device;

[0174] [Figure 24] 24 illustrates an exemplary, non-limiting process illustration based at least in part on mobile communication signals according to at least some embodiments of the present disclosure. In some embodiments, the exemplary process of FIG. 24 may include at least the following steps: in step 2401, recording, by an access control platform, an expected data record as an access control mechanism for accessing an access-restricted digital resource, the expected data record including an access code and an identity linked to a computing device, where the access code is associated with the access-restricted digital resource and access via the computing device is restricted; and where the expected data record is generated while an access controller interface element is displayed on a screen of the computing device, where the access controller interface element is operatively linked to the access-restricted digital resource. In step 2402, the access control platform receives, while the access controller interface element is displayed, a mobile-originated communication having data including the access code and the ID; in step 2403, the access control platform performs a verification of the expected data record with the mobile-originated communication; and in step 2404, if the verification is successful, the access control platform, based on at least a portion of the data, instructs the cellular communications network to perform at least one action using the cellular network-hosted access control schema to generate a session record associated with the ID; and in step 2405, the access control platform configures a computing device to unlock access-restricted digital resources for access via the computing device. [Figure 25] 25 illustrates an exemplary, non-limiting process illustration based at least in part on mobile communication signals according to at least some embodiments of the present disclosure. In some embodiments, the exemplary process of FIG. 25 may include at least the following steps: in step 2501, receiving, by an access control platform, an expected data record as an access control mechanism for accessing an access-restricted digital resource, said expected data record including an access code and an identity linked to a computing device, where the access code is associated with the access-restricted digital resource and access via the computing device is restricted; and wherein said expected data record is generated while an access controller interface element is displayed on a screen of the computing device, where the access controller interface element is operatively linked to the access-restricted digital resource. In step 2502, the access control platform receives a mobile-originated communication having data including the access code and the ID while the access controller interface element is displayed; in step 2503, the access control platform performs a verification of the expected data record with the mobile-originated communication; and in step 2504, if the verification is successful, the access control platform, based on at least a portion of the data, instructs the cellular communications network to perform at least one action using the cellular network-hosted access control schema to generate a session record associated with the ID; and in step 2505, the access control platform controls the computing device to unlock an access-restricted digital resource for access via the computing device. Exemplary, non-limiting embodiments of access control network architectures, systems, components and / or elements programmed utilizing novel cellular signal access control protocols with anticipated key and machine learning techniques to access restricted resources / services and to identify, rank, modify and / or control automated programmable entities (e.g., robots / bots) and their visual schemas, and methods of use thereof.

[0175] Some exemplary non-limiting technical problems addressed herein One technical issue addressed in this disclosure is that legacy and analog username and password (UNAP)-based security may be significantly compromised given that many users choose convenience over security by choosing easy-to-remember passwords rather than stronger, more cryptic ones, and / or by reusing the same passwords across multiple services. For example, large-scale data security breaches and privacy concerns have eroded online trust, further eroding UNAP methods of accessing services due to increased risk and exposure. Typically, users may be increasingly reluctant to disclose personal data to online entities. Another technical problem addressed in this disclosure is the possibility that a user may enter their identity via a keypad or keyboard, which may pose a fundamental vulnerability, for example, because keystrokes are typically not encrypted when pressed (entered) and may be intercepted, for example, by keyloggers and / or remote control software. Thus, no matter how secure an Internet communication protocol is, data manually entered into a device using a keypad or keyboard may be captured in clear text or an equivalent related text code (e.g., ASCII) by a malicious attacker.

[0176] Yet another technical problem addressed in this disclosure is that usernames and passwords may often be required to be stored by third-party service providers who may not take necessary data protection precautions. Numerous large-scale data breaches and leaks have occurred, leaving millions of online identities exposed and vulnerable. Yet another technical issue addressed in this disclosure is the alarming frequency with which malicious actors, such as scammers and phishers, may extract login credentials from unsuspecting users using computer-driven social engineering techniques. Yet another technological issue addressed in this disclosure is that with the advent of smartphones and app stores, countless application providers have gained access to computer data storage, device controllers, and functions of highly personal data, such as contacts, phone events, screen recording, and access to the camera and / or keypad. For example, users may habitually grant permissions to third-party applications and / or application functions requested by software that may be outside the scope of the service being offered. As a result, at least some view the modern digital mobile phone as a security Pandora's box. Yet another technical issue addressed in this disclosure is the shortcomings of securely verifying users via cell phone numbers, given that many Internet services use MSISDN to provide two-factor authentication (2FA) communications. For example, in one typical 2FA procedure, the Internet service's computing device can use MSISDN to send one-time passcodes (OTPs) to a registered mobile device via SMS and / or phone call, and then require the user to re-enter these codes for anticipated Internet authentication sessions.

[0177] Yet another technical issue addressed in this disclosure is that, given that many services knowingly provide APIs for automating core components of their service offerings, there may be no known way to effectively detect BOTS (computer programs configured / programmed to perform automated repetitive tasks) operating on a service platform on a large scale, such as automatically replying to messages, scheduling replies to messages, selectively responding to messages by topic and / or keyword, automatically following other users, creating user lists, identifying market trends, automatically responding to trends, conducting surveys, conducting online polls, distributing news, etc. Online social media platforms (e.g., Meta TM / Facebook TM / WhatsApp TM (Meta Platforms, Inc., CA), Twitter TM (e.g., Twitter, Inc., CA) may lack automated methods to detect, highlight, and / or tag automated computer processes (e.g., "BOTS" or robots) that may register as humans and disguise themselves. For example, while BOTS provide a valuable automated service, they may not only artificially inflate their subscriber numbers, but may also use computer technology for nefarious purposes, such as spreading false or misleading information to sway public opinion or undermine free speech or the democratic process.

[0178] For example, there is a technological need for authentic entities (humans) and their inputs to be clearly distinguished and clearly presented from inputs created by artificial entities (automata, BOTS) whose content and intent may be malicious. At least one reason this separation is so fundamental to restoring balance online is the classic problem regarding the protection of free speech in the digital ecosystem: the issue between allowing free speech and ensuring truth based on factual data. This balance is literally a numbers game. For example, because bots are typically artificially generated and programmatically injected into online systems, there can be vast numbers of them, far exceeding the number of humans who need to manually register to participate online. This statistic alone creates an uneven playing field of epic proportions, both statistically and concretely, regarding not only the provenance of the data but also its trustworthiness and its ability to sway online opinion at will, for example, BOTS can increase or decrease the prominence of posts (tweets), posing an existential threat to democratic, free, and fair processes (e.g., elections). For example, this issue is accentuated by online forums that may allow people (and BOTS) to post, and thus the percentage of the online base that may be BOTS will typically not be accurately determined, which could have a negative knock-on effect on digital advertising to the base, for example, but not limited to: advertising that sells on digital views (also known as "brand" or "mindshare" advertising) rather than necessarily conversions (click-throughs and product purchases) because, even though they are not considered "viewed" (by potential customers), they are currently billed as such if at least some of the ads are unwittingly delivered to BOTS.

[0179] Yet another technical problem addressed in this disclosure is that some 2FA processes / systems may allow a malicious actor to gain access to telephone-based messaging (e.g., SMS) and / or telephony capabilities to intercept 2FA codes and automatically take control of a user's cellular service-enabled computing device to return the 2FA code via IAPP, completing the authentication loop without user intervention or the user's awareness of the consequences of their actions to facilitate the malicious actor. Yet another technical problem addressed in this disclosure is that legacy SS7 signaling networks typically utilized to transport these 2FA codes and calls may have numerous vulnerabilities that allow malicious actors with access to SS7 peering points to redirect and / or intercept such mobile termination events and compromise these authorization codes and / or signals. For example, at least some vulnerabilities may result when, for example, the source of the SS7 messages is not authenticated and critical network control messages can be injected into the SS7 network from one or more entities posing as mobile phones and / or switching elements. Thus, for example, but not limited to, a malicious actor could forge mobile phone location updates (or similarly overwrite subscriber information, such as HLRs), hijack mobile phone routing, and covertly intercept and thereby insert phone calls and texts. Yet another technical problem addressed in this disclosure is that some authenticator applications can be programmed to push notifications over a data connection to registered cellular devices, prompting user confirmation before granting access to online resources (e.g., services). Yet another technical problem addressed in this disclosure is that at least some authenticator applications, while purporting to overcome at least one or more of the identified 2FA problems, may trigger attention deficit disorder (ADD), poor muscle memory, and / or poor hand-eye coordination, resulting in users habitually and / or inadvertently granting access. For example, ADD can manifest as bipolar disorder, and a user suffering from ADD may, for example, press or select a button labeled "green" or "yes" when they intended to press a button labeled "red" or "no." Yet another technical problem addressed in this disclosure is that a potentially significant number (e.g., potentially billions) of cellular users may only use so-called "basic" phones that typically lack so-called "advanced" data push notification services (e.g., web push notifications, rich push notifications carrying images, emojis, etc.), and are unable to take advantage of such "high-end" authentication protocols.

[0180] Yet another technical issue addressed in this disclosure is the existence of a phenomenon known as "click farming," in which certain user interactions preclude automation through programmatic direction, for example, by utilizing hundreds or thousands of programmed mobile phones and / or low-skilled and / or low-wage human resources (primarily in developing countries) to perform automatic (mobile phones programmed to activate user interface elements) (bot mobile phones) and / or manual clicks (e.g., manually activating user interface elements) on behalf of malicious actors to circumvent certain authentication processes. For example, human click farms or hybrid click farms using bot mobile phones with human input can be used to effectively bypass Captcha-type systems that may present visual recognition tasks and / or puzzles to be solved designed to distinguish between human and machine input. Furthermore, so-called "click farming" typically places a significant strain on computing resources and network traffic, reducing availability for other uses. Some exemplary non-limiting technical solutions described herein As described in detail herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein, for example, by providing security enhancement methods, access control network architectures, and systems for identifying and authenticating users in various environments, including, without limitation, online. For example, at least some embodiments of the present disclosure may leverage secure Mobile Originating Signaling capabilities over digital networks to implement cellular-based authentication that provides reliable, seamless, and frictionless user identity authentication for accessing digital products and / or services at scale. As detailed herein, at least some embodiments of the present disclosure may, for example, but not limited to, reduce the dependency, and resulting vulnerability, from a user identifying themselves by enabling a trusted Intelligent Network (IN), e.g., a cellular network, to securely provide identification outside the realm / band of the Internet without user intervention, thereby eliminating additional external points of compromise (e.g., malicious actors from outside the IN / cellular network).

[0181] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein, for example, but not by way of limitation, by programming an Internet Application Programming Interface (IAPP) to connect, via an application programming interface (API), to a so-called "STARKEY" platform (which may be referred to herein interchangeably as an "Access Control Platform") of the exemplary disclosure, requesting and then presenting to the user a challenge including, but not limited to, a randomly generated series (sequence) of numbers (e.g., a sequence of numbers, a randomly generated alphanumeric sequence, etc., which may also be referred to herein as an expected access control digital key). In some embodiments, the randomly generated series of numbers (expected access control digital key) may be prefixed with one or more predetermined or randomly selected symbols (e.g., a star symbol (*), a symbolic routing prefix) before being presented to the user, collectively forming, interchangeably herein, a "STAR Challenge," a "STAR Random Challenge," a "STAR Randomized Phone Number," a "STAR Random Challenge & Response," or a "STAR Challenge." In at least some embodiments, an exemplary STARKEY platform (access control platform) may be programmed to generate / form the Star Challenge. In at least some embodiments, another computing device (e.g., a user computing device, a provider computing device as described herein) may be programmed to generate / form the Star Challenge by prefixing / appending / adding one or more predetermined symbols to a randomly generated sequence of numbers (the expected access control digital key) before it is presented to the user.In at least some embodiments, the star challenge and expected access control digital key are configured to be recognized by the user as a series of telephone digits and symbols that the user can select and / or enter on a telephone keypad. For example, both the star challenge and expected access control digital key may be configured to have a sufficiently suitable number of random digits such that a malicious actor would need to attempt millions, billions, trillions, or even trillions of permutations, making brute force attacks potentially unlikely or impossible given their cellular origination and sufficiently suitable short-lived duration as disclosed herein.

[0182] As detailed herein, and by way of example only and not limitation, billions of users / people own personal mobile phones, and every mobile phone has a unique digital subscriber ID, known, for example, as an MSISDN (Mobile Subscriber Integrated Services Digital Network, also known as a Mobile Station International Subscriber Directory Number). Each MSISDN is the telephone number that users dial to reach each other. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein, for example, by utilizing each mobile phone number as a ubiquitous / unique personal digital identity (UPDI). For example, registering a user online using their mobile phone number provides a globally unique ID (GUID) that seamlessly interfaces with contact lists (e.g., personal phone address books), enabling IAPP linking and viral propagation across social address books. In some embodiments, the GUID may allow Internet services (e.g., Internet publishers, Internet businesses) to deliver over-the-top (OTT) telephony and / or messaging applications using existing, known phone numbers as service addresses and IDs (e.g., user IDs, computing device IDs, etc.). For example, the OTT telephony and / or messaging applications may include, but are not limited to, presence-based directories, video chat, multi-party conferencing, screen sharing, and / or PSTN calling. For example, the OTT telephony and / or messaging applications may be, but are not limited to, "thick" clients, browser-based "thin" clients, and / or Web Real-Time Communications (WebRTC)-based "thin" clients.

[0183] For example, if a cellular user A has a cellular service-enabled computing device (e.g., mobile phone / smartphone) with an MSISDN-A registered with an Internet App (IAPP) using the MSISDN-A as its ID (a modified phone address book entry), the IAPP and / or other associated programs / applications / network(ies) may determine that for a communication addressed to user A (MSISDN-A) from another user of the IAPP, the recipient's cellular device MSISDN-A is registered and connected to the IAPP, and therefore may route the communication OTT using an Internet connection (e.g., an Internet network) rather than routing the communication over the cellular network. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein by registering a user with an identity (e.g., MSISDN) as described herein to facilitate any contacts (e.g., MSISDN) to be registered with an IAPP service (e.g., social media app / website) may be indicated as such in an appropriately modified phone book program, and contacts not yet registered may be invited to join the IAPP community of the MSISDN via onboarding over a network (e.g., IN, cellular network, etc.) dependent on the modified phone book program. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein, for example, but not limited to, recording a randomly generated sequence of numbers (e.g., an expected access control digital key), or recording the randomly generated sequence of numbers with a symbol (e.g., one or more STAR challenges), or other similarly suitable data, as an expected record in non-transitory storage, whereby the access control platform can be programmed to await receipt of a sequence of network (e.g., IN or cellular network) mediated signals from a yet-unknown cellular device that exactly matches the expected record. In some embodiments, once this stored expectation is met by the user, for example by dialing a series of randomized digits displayed in the form of a STAR Challenge as a telephone number on a cellular device, the cellular network routes such a "STAR" call request to the service STARKEY platform (access control platform), which can securely identify the cellular device that emits the matching STAR address signal (STAR ​​Challenge recorded in the expectation) and extract a cellular network-provided caller ID (e.g., MSISDN) determined from a cellular profile associated with the user and / or device (e.g., SIM) stored in the cellular network, also referred to herein as a "STAR Challenge Response."

[0184] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein, for example, but not limited to, programming an IAPP to present a randomly generated series of numbers (e.g., an expected access control digital key, part of a STAR Challenge) as a graphical user interface (GUI) element (which may also be referred to herein as a STAR Challenge element) (e.g., a button with a text label of STAR Challenge, displaying the STAR Challenge as a randomized series of numbers as a click-to-call button / link). In some embodiments, an exemplary STAR Challenge element may be programmed to appear in the form of a telephone button (e.g., a green button with an icon / image of a telephone or telephone receiver), displaying a STAR Challenge containing a series of randomly generated numbers (e.g., an expected access control digital key) that the user will activate to dial (STAR ​​Challenge Phone Number), and / or a telephony QR code encoded with the STAR Challenge (STAR ​​Challenge Phone Number) that a user can scan rather than manually enter the STAR Challenge or the series of randomly generated numbers therefrom when using the IAPP on a desktop / laptop computer or a virtual reality (VR) headset that does not have native cell phone dialing capabilities. In some embodiments, without limitation, upon activating (e.g., "tapping") the STAR Challenge button or scanning a QR code encapsulating the STAR Challenge Phone Number, the cell phone dialer may then be presented with the automatically entered / entered randomized phone number as the dialing address for completing the STAR Challenge response.

[0185] As described in more detail herein, at least some embodiments of the present disclosure may involve, for example, but not limitation, a user pressing a number including a series of randomized digits (a prospective access control digital key) or a number including a series of randomized digits prefixed with a symbolic routing prefix (e.g., a STAR Challenge random phone number), such that the user presses a GUI element (e.g., a button in the shape of a green phone icon and / or a button displaying a green phone icon), causing the user's associated cellular device or the user's associated cellular service-enabled computing device (e.g., a tablet) to emit and, without limitation, transmit a telephony-type address signal (e.g., a STAR Challenge address signal) wirelessly to the cellular network, and then execute an authentication, authorization, and accounting (AAA) protocol to securely verify and authenticate the user's associated cellular device or the user's associated cellular service-enabled computing device (e.g., a tablet) based on one or more secret internal network keys (e.g., Ki stored locally on the SIM and internally in an HLR on the network) and / or one or more security algorithms, e.g., A3 / A8 or COMP128. These include, but are not limited to, challenge-response algorithms. In some embodiments, upon passing the AAA verification procedure, the network provides one or more internal network identifiers (e.g., MSISDN, ICCID, IMEI, etc.) associated with the cellular device (SIM / IMSI) and routes the star-prefixed call to the STARKEY platform. The STARKEY platform may be programmed to determine when the received address signal is expected and, optionally, time-based active, for example, by performing a check (e.g., by matching) of the received address signal with, for example, a stored randomized series, and that the call would have been received within an unexpired timer interval. Upon confirming the expected active challenge, the STARKEY platform extracts the MSISDN associated with the device that originated the randomized address signal. Thus, upon receiving an expected and matching response to the STAR challenge, including a highly randomized number as disclosed herein, the STARKEY platform may be programmed to utilize the provided cellular ID to seamlessly, securely, and uniquely identify the user's associated IAPP.

[0186] As described in more detail herein, at least some embodiments of the present disclosure provide a method for, by way of example and not limitation, providing that only a user (human) currently viewing a STAR Challenge displayed on an Internet-enabled computing device (e.g., tablet, desktop computer, mobile phone, VR headset, ATM machine, gaming terminal) can respond (e.g., dial, send SMS) with an identical sequence and series of random digits (e.g., Star Challenge Response) within a predetermined time interval (e.g., 1-60 seconds, less than 5 minutes, less than 10 minutes, 15 minutes, etc.). Furthermore, given that the response received by the STARKEY Platform is OUT of Band (OOB) over a cellular network, rather than INB in ​​an IAPP Internet data communication channel, for example, the response (e.g., Star Challenge Response) to a random challenge (e.g., Star Random Challenge) cannot be intercepted over the Internet or injected via the Internet. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to address one or more of the technical problems identified herein, for example, by technically enabling third-party service providers with so-called "STARKEY" APIs (e.g., an exemplary, non-limit...

Claims

1. It is claimed that 23. A method comprising: executing, by a processor of said computing device, at least one application program instruction for displaying, on a screen of said computing device, said access controller interface element and an access code; the access controller interface element is operatively linked to an access restricted digital resource; transmitting an access request over a cellular network based on at least one activity performed by a processor of the computing device with the access controller interface element; The access request comprises data including: Access code and An identity linked to a computing device. receiving, by a processor of the computing device, via the Internet, in response to transmitting the access request, at least one access program instruction for unlocking, via the application program, an access restricted digital resource for access via the computing device; receiving at least one access program instruction for unlocking the access restricted digital resource after the access request is transmitted over a cellular network; and executing, by a processor of said computing device, at least one access program instruction for unlocking an access-restricted digital resource for access via said computing device;

2. 23. A method comprising: An expected data record as an access control mechanism for accessing the access-restricted digital resource is recorded by the access control platform, the expected data record comprising: Access code and An identity linked to a computing device. the access code is associated with the restricted access digital resource; receiving, by the access control platform, a mobile-originated communication having data including: Access code and identity; performing, by the access control platform, a check of the expected data record with the mobile originated communication; If the verification is successful, the following will occur: instructing, by the access control platform, the cellular communications network to generate a session record associated with the identity based on at least a portion of the data; and authorizing, by the access control platform, the computing device to unlock an access-restricted digital resource for access via the computing device;

3. 1. A computing device comprising: at least one processor in communication with a non-transitory computer readable medium storing software instructions; The software instructions, when executed, cause at least one processor to: Based on the detection of the at least one activity, sending an access request having data including: Multipart Multifunction Access Control Sequence and At least one identity linked to a computing device; The multi-part, multi-function access control sequence comprises: At least one symbol, Access Code Specific access control digital key. receiving at least one access program instruction for unlocking at least one access-restricted digital resource for access via the computing device in response to the access request; receiving the at least one access program instruction for unlocking the at least one access-restricted digital resource; The access code of the multi-part multi-function access control sequence is accepted by the cellular network; a particular access control digital key of said multi-part, multi-function access control sequence is verified to match an expected access control digital key; Executing the at least one access program instruction to unlock at least one access restricted digital resource for access via the computing device.

4. 23. A method comprising: generating, by said access control platform, an access control digital key expected to authenticate a computing device for accessing at least one access-restricted digital resource; receiving, by the access control platform, a mobile-originated communication; Specific access control digital keys and An identity linked to a computing device. verifying, by the access control platform, the particular access control digital key in the access request data with the expected access control digital key; transmitting, by the access control platform, the access authentication indicator if the verification is successful; and The access authentication indicator is configured to cause at least one access-restricted digital resource to be unlocked for access at the computing device.

5. A computer platform comprising: at least one processor in communication with a non-transitory computer readable medium storing application program instructions; The application program instructions, when executed, cause at least one processor to: receiving, via the computer network, from an online entity an action performance request requesting performance of at least one action with the computer platform; Receiving the expected access control digital key from the access control platform. Send the following computer command: causing the access control platform to generate an access authentication indicator upon receiving an expected access control digital key from the computing device; determining, in response to transmitting the computer instructions, a lack of receipt from the access control platform of the access authentication indicator associated with the online entity; and Suspends the execution of at least one action by an online entity.

6. 23. A method comprising: receiving, by at least one processor, a personalized Universal Resource Locator link (PURL); Domain name transmitting, by the at least one processor, the MACRO band parameters based on user interaction with a graphical user interface (GUI) and via Internet Protocol-based communications; received by at least one processor in response to a transmission of a MACRO band parameter of the multi-part multifunction address signaling sequence; MICRO band part corresponding to MICRO band parameters and MACRO band part that corresponds to the MACRO band parameter. transmitting, by at least one processor over a cellular communications network, a session request having data including a multi-part multi-function address signaling sequence; Sending the session request results in a session activity controlling the Internet platform between the first digital wallet and a second digital wallet based on the domain name and the MACRO band parameters. The microband portion of the multi-part multi-function address signaling sequence is accepted by the cellular communications network; At least one piece of data is verified to match an expected session record.

Images