Method and system for access control

Abstract

A method and system for access control is provided, the method comprising: executing, by a processor of a computing device, application instructions to display an access controller interface element and an access code on a screen of the computing device, the access controller interface element operatively linked to an access restricted digital resource; transmitting, by the processor, an access request over the cellular network based on an activity performed using the access controller interface element, including an access code and an identity linked to the computing device; the processor receives an access program instruction through the Internet to respond to transmission of the access request and receive the access program instruction through the application program so as to unlock access to the limited digital resource for access through the computing device; and executing, by the processor, the access program instructions to unlock the access restricted digital resources for access by the computing device.

Description

[0001] This application is a divisional application of the Chinese national phase application of the PCT application with the application date of December 30, 2022, the international application number of PCT / US2022 / 054312, and the invention name of "Permission-based control network architecture and system, modifying cellular network components and elements to host permission control mode, aiming to promote electronic point-to-point communication sessions between member computing devices based on cellular communication signals based on new cellular communication protocols and methods of use thereof". The entry date of this Chinese national phase application into the Chinese national phase is July 1, 2024, and the application number is 202280087242.1.

[0002] Priority claim

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

[0004] Copyright Notice

[0005] A portion of the disclosure of this patent document contains material which 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 copyright rights whatsoever. The following notice applies to the software and data and drawings that constitute a part of this document: Copyright © Ari Kahn, All rights reserved. Technical Field

[0006] The subject matter relates to permission-based control network architectures and systems having cellular network components and elements modified to a host permission control mode designed to facilitate electronic peer-to-peer communication sessions between member computing devices based on cellular communication signals, in accordance with a new cellular communication protocol and methods of use thereof. Background Art

[0007] Typically, cellular communication signals associated with cellular communications may utilize a Basic Call State Model (BCSM) and control points that control communication setup, progression, and other call-related operations within an Intelligent Network (IN) (communications network). In one example, a communication may be a mobile-originated telephone call request. A network switching element (e.g., an MSC) may receive the call setup request and, in turn, request call handling instructions from a network control element (e.g., an SCP / SCF). The network control element may rely on one or more additional devices / systems (e.g., an OCS) to determine various aspects of the call, including the decision to proceed with the call. Security based on traditional and analog username and password (UNAP) systems has been severely compromised, as many users choose convenience over security, selecting easier-to-remember passwords over stronger, more obscure ones, and reusing the same passwords across multiple services. Large-scale data security breaches and privacy issues have undermined online trust, and the increased risk and exposure further undermine UNAP methods of accessing services. Users are also increasingly reluctant to disclose personal data to online entities.

[0008] For example, in the digital world, to access various networks, users often need to enter a pseudonym and password to identify themselves, thereby registering and accessing services. Typically, a username can include the user's real name, pseudonym, email address, nickname, and any other relatively easy-to-discover personal information about the user. Summary of the Invention

[0009] In some embodiments, the present disclosure provides various exemplary technical improvement methods, one of which may include but is not limited to the following steps: establishing, by a processor of a sender computing device, a peer-to-peer communication session with a receiver computing device through an application, at least: receiving a personalized universal resource locator link (PURL) including: a domain name associated with a session control Internet platform hosting an authority control architecture, and

[0010] at least one first identity associated with a recipient computing device;

[0011] Among them, PURL is communicatively coupled with the permission control mode of the session control Internet platform;

[0012] executing at least one application program instruction to display a PURL-based graphical user interface (GUI) comprising a plurality of GUI elements, each GUI element being programmed to allow a user of a sender computing device to select or input MACRO band parameters associated with a peer-to-peer communication session;

[0013] linking the MACRO band parameters and the at least one first identity to a recipient computing device of the session-controlled Internet platform based on user interaction with the GUI and through Internet protocol-based communications;

[0014] In response to sending MACRO band parameters and at least one first identity from a session controlled internet platform, receiving a multi-part multi-function address signaling sequence, comprising:

[0015] MICRO band part, corresponding to MICRO band parameters and

[0016] MACRO band part, corresponding to MACRO band parameters;

[0017] In a peer-to-peer communication session, a session request is transmitted over a cellular communication network, and the data includes:

[0018] Multi-part multi-function address signaling sequence and

[0019] at least one secondary identity;

[0020] wherein transmitting the session request causes the session control internet platform to initiate activity between a first digital wallet associated with at least one first identity and a second digital wallet associated with at least one second identity based on the domain name and the MACRO band parameter:

[0021] The MICRO band portion of the multi-part multi-function address signaling sequence has been accepted by cellular communication networks, and

[0022] Confirm that at least a portion of the data matches an expected session record associated with the session controlling Internet platform.

[0023] In some embodiments, the present disclosure provides various exemplary technical improvement methods, wherein one method may include, but is not limited to, at least the following steps: generating a personalized universal resource locator link (PURL) via a session control Internet platform;

[0024] The PURL is:

[0025] communicatively coupled to the permission control mode and configured to establish a peer-to-peer communication session between a sender computing device and a recipient computing device;

[0026] The PURL includes:

[0027] The domain name associated with the session control Internet platform that hosts the authority control architecture, and

[0028] at least one first identity associated with a recipient computing device;

[0029] transmitting the PURL to a receiving computing device via the session controlled Internet platform;

[0030] Receiving, the session control Internet platform, after transmitting the PURL to the recipient's computing device, mobile initiates the communication, whose data includes:

[0031] Multi-part multi-function address signaling sequence, including:

[0032] MICRO band part, corresponding to MICRO band parameters and

[0033] The MACRO band part, corresponding to the MACRO band parameters, and

[0034] at least one secondary identity;

[0035] Performing an activity between a first digital wallet associated with at least one first identity and a second digital wallet associated with at least one second identity based on a domain name and a MACRO band parameter via a session control internet platform:

[0036] The MICRO band portion of the multi-part multi-function address signaling sequence has been accepted by cellular communication networks, and

[0037] Confirm that at least part of the data matches the expected session record. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Various embodiments of the present disclosure can be further explained with reference to the accompanying drawings, in which similar structures are represented by similar reference numerals throughout the several views. The drawings shown are not necessarily drawn to scale, but rather generally emphasize illustrating the principles of the present disclosure. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ one or more of the illustrative embodiments.

[0039] Figure 1 are illustrative, non-limiting examples of remote control access schemes in accordance with at least some embodiments of the present disclosure.

[0040] Figure 2 is a non-limiting example of a network architecture according to at least some embodiments of the present disclosure, including at least one smart element.

[0041] Figure 3 are illustrative, non-limiting examples of intercommunication devices according to at least some embodiments of the present disclosure.

[0042] Figure 4A is an illustrative, non-limiting example of a circuit-switched star logic channel in accordance with at least some embodiments of the present disclosure.

[0043] Figure 4Bis a non-limiting example of a packet-switched star logical channel in accordance with at least some embodiments of the present disclosure.

[0044] Figure 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.

[0045] Figure 6 is an illustrative, non-limiting example of an action millisecond event timeline in accordance with at least some embodiments of the present disclosure.

[0046] Figure 7 is an illustrative, non-limiting example of an abstract progression of action events in accordance with at least some embodiments of the present disclosure.

[0047] FIG8 is a diagram of manual selection (existing technology).

[0048] Figure 9 are illustrative, non-limiting examples of automatic selection in accordance with at least some embodiments of the present disclosure.

[0049] FIG10 shows various action methods (existing technology).

[0050] Figure 11A is an illustrative, non-limiting example of the singularity property of an active channel approach (single active channel) in accordance with at least some embodiments of the present disclosure.

[0051] Figure 11B is another illustrative, non-limiting example of the singularity property of the active channel method (single active channel) in accordance with at least some embodiments of the present disclosure.

[0052] Figure 12A are illustrative, non-limiting examples of action diagrams in accordance with at least some embodiments of the present disclosure.

[0053] Figure 12B is an illustrative, non-limiting example of yet another action diagram in accordance with at least some embodiments of the present disclosure.

[0054] FIG. 13A shows various action methods (prior art).

[0055] Figure 13B are illustrative, non-limiting examples of singularity properties of active channels in accordance with at least some embodiments of the present disclosure.

[0056] Figure 14 is a comparative graph illustrating results of at least one technology improvement prediction according to at least some embodiments of the present disclosure.

[0057] Figure 15A are illustrative, non-limiting examples of processing algorithms for utilizing cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0058] Figure 15B is an illustrative, non-limiting example of utilizing a static state processing model matrix for a cellular communication signal in accordance with at least some embodiments of the present disclosure.

[0059] Figure 15C is a non-limiting example of a telephone and natural binary encoding address scheme in accordance with at least some embodiments of the present disclosure.

[0060] Figure 16 is a non-limiting flow diagram of events / actions for a cellular communication protocol in accordance with at least some embodiments of the present disclosure.

[0061] Figure 17 is a non-limiting flow diagram of events / actions for a desired cellular communication protocol in accordance with at least some embodiments of the present disclosure.

[0062] Figure 18 is a non-limiting flow diagram of events / actions for a cellular communication protocol in accordance with at least some embodiments of the present disclosure.

[0063] Figure 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.

[0064] Figure 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.

[0065] Figure 19C is an illustrative, non-limiting example of a circuit-switched cellular communications signaling protocol with automatic routing in accordance with at least some embodiments of the present disclosure.

[0066] Figure 20 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0067] Figure 21 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0068] Figure 22 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0069] Figure 23 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0070] Figure 24are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0071] Figure 25 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0072] Figure 26A is an illustrative, non-limiting example of an access control network architecture utilizing a cellular signal access control approach with contemplated digital keys, consistent with the novel communication protocol of at least some embodiments of the present disclosure.

[0073] Figure 26B is an illustrative, non-limiting example of a binary robot detection process, according to at least some embodiments of the present disclosure, through inference based at least in part on cellular communication signals.

[0074] Figure 26C is an illustrative, non-limiting example of one aspect of a binary robot detection process by reasoning based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0075] Figure 27 is an illustrative, non-limiting example of a method for utilizing cellular signal identity management based on the novel communication protocol and access control network architecture of at least some embodiments of the present disclosure.

[0076] Figure 28 is an illustrative, non-limiting example of utilizing a contemplated cellular signaling management approach based on a novel communication protocol and access control network architecture according to at least some embodiments of the present disclosure.

[0077] Figure 29 is an illustrative, non-limiting example of an authentication management method utilizing cellular signaling that is based on the novel communication protocol and access control network architecture of at least some embodiments of the present disclosure.

[0078] Figure 30 is an illustrative, non-limiting example of an access control network architecture utilizing a cellular signal access control method with contemplated digital keys, consistent with the novel communication protocol of at least some embodiments of the present disclosure.

[0079] Figure 31 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0080] Figure 32 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0081] Figure 33 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0082] Figure 34 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0083] Figure 35 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0084] Figure 36 are illustrative, non-limiting examples of processes based at least in part on cellular communication signals in accordance with at least some embodiments of the present disclosure.

[0085] Figure 37 is an illustrative, non-limiting example of one aspect of at least some embodiments of the present disclosure.

[0086] Figure 38 is an illustrative, non-limiting example of a Star P2P digital communication mode for token exchange (TAP).

[0087] Figure 39 is an illustrative, non-limiting example of a Star P2P communication model for tipping, real-world services and / or products (TIP).

[0088] Figure 40 is an illustrative, non-limiting example of a star P2P invoice URL and schema.

[0089] Figure 41A is an illustrative, non-limiting example of a star-shaped micro / macro band signaling symbol.

[0090] Figure 41B is an illustrative, non-limiting example of a star-shaped micro / macro band control / session record keeping matrix.

[0091] Figure 41C is an illustrative, non-limiting example of a star-shaped micro / macro band authority verification flow chart.

[0092] Figure 42 is an illustrative, non-limiting example of a desired flow chart for a star-shaped micro / macro band.

[0093] Figure 43 is an illustrative, non-limiting example of a star-shaped micro / macro band communication session (eg, transaction) flow diagram.

[0094] Figure 44is an illustrative, non-limiting example of the Star Internet Of Things token payment model (IOT).

[0095] Figure 45 is an illustrative, non-limiting example of a Star Cellular authorized banking exchange session (eg, transaction). DETAILED DESCRIPTION

[0096] Various detailed embodiments of the present disclosure are disclosed herein with reference to the accompanying drawings; however, it should be understood that the disclosed embodiments are merely illustrative. In addition, each example associated with the various embodiments of the present disclosure is intended to be illustrative rather than restrictive.

[0097] Throughout this specification, unless the context clearly dictates otherwise, the following terms have the meanings explicitly associated herein. The phrases "in one embodiment" and "in some embodiments" as used herein do not necessarily refer to the same embodiment, although they may. Additionally, the phrases "in another embodiment" and "in some other embodiments" as used herein 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.

[0098] All systems, platforms, devices (including computing devices supporting cellular services, such as mobile phones), components, elements, and corresponding methods, rules, principles, code, and policies, as disclosed herein and programmed into related hardware, software, or a combination of hardware and software, are collectively referred to as the STAR Operating System (*OS or *O / S). For example, but not limited to, the STARKEY platform (also referred to herein as the STAR platform and / or STARPAY platform), STARGATE protocol, STAR band signaling protocol, STAR cellular access control rules / code / policies, and other STAR components referenced herein may be programmed to run and / or operate in accordance with the *O / S. In some cases, the connection between one entity of the *O / S and another entity may be physically or logically operated on the same network element or local area network, where two or more entities of the *O / S are therefore operated on a single hardware platform and / or network. In other cases, the connection between the STAR entities may be remote, between different network elements or through a network connection across a distance. Each embodiment may use different hardware, software, and interconnection architectures to implement the illustrative functionality described for the *O / S.

[0099] This article will discuss some illustrative, non-limiting technical issues

[0100] One technical problem addressed by the present disclosure is that users' online experiences are being impacted by digital content (e.g., digital advertisements) that is becoming increasingly intrusive, disruptive, and pervasive. For example, some content providers intentionally irritate online users with a flood of digital advertisements and then extort monthly payments from users for software solutions designed to free online users from the spam created by the digital content providers.

[0101] Another technical issue involved in the present disclosure is that while many Internet browsers (applications) may provide digital ad blocking technology to suppress online advertisements, some browser creators themselves may be in conflict because, in suppressing unwanted digital content (e.g., digital advertisements), browser creators may confuse and / or make it difficult for online users to configure the Internet browser to reduce and / or delete tracking of the user's online activities and obtain the same online experience without giving up online privacy.

[0102] However, another technical issue addressed in the present disclosure is that digital advertisements may also innocently present themselves as "sponsored content," but often take the form of "clickbait," images, and / or links that appear to lead to newsworthy stories and / or entertaining videos, when in fact various online technologies may allow unscrupulous actors to cleverly design deceptive digital advertisements to extract and / or steal personal information and / or conduct ransomware attacks, potentially leading to an undermining of user trust in online publishing.

[0103] However, another technical issue addressed in the present disclosure is that online users may perceive a lack of online privacy and increased distrust in digital technologies, such as, but not limited to, the frequency of large-scale data security breaches, which may significantly reduce users' trust that their data and / or activities (e.g., electronic payment activities) will be protected by digital security measures / techniques used by unknown and / or known third parties.

[0104] However, another technical problem addressed in the present disclosure is that online technologies generally lack the ability to efficiently execute individual online transactions, such as, but not limited to, executing digital payments for individual service units (SSUs), such as, but not limited to, a single online article of interest rather than an entire online publication, a single music track rather than an entire album, and similar other units of digital content, and / or digital services, and / or real services with digital components, and / or any combination thereof.

[0105] However, another technical problem addressed in the present disclosure is that online experiences currently still lack micro-business capabilities (e.g., involving, for example, but not limited to, one or more minor units (e.g., one or more cents, etc.) of one or more currencies as defined by the ISO 4217 standard published by the International Organization for Standardization). For example, traditional bank switches that charge high transaction fees are not suitable for small-amount billing.

[0106] For example, but not limited to, technical issues with digital technology may arise from the technical complexities of setting up and / or managing cryptographic wallets, which generally also require users to be responsible for protecting their digital keys, and in addition, the complexity of actually conducting transactions from such digital wallets due to, for example, but not limited to, the computational intensity and / or digital resource requirements involved in executing and / or recording digital transactions (e.g., CPU / GPU processing power requirements, computer memory requirements, electricity requirements, etc.).

[0107] Another technical issue addressed in this disclosure is that cryptocurrencies may be more susceptible to valuation fluctuations and the potential for numerous bad actors to manipulate the market using various digital technologies, which could translate into substantial real losses in fiat currency.

[0108] Another technical problem addressed by the present disclosure is that, based on a BCSM and control points / elements that may manage the setup, progression, and billing of communications in a typical intelligent network (IN) (e.g., a network architecture specified in the ITU-T Q.1200 series of Recommendations), a typical IN is limited in that it applies a communication tariff only on a pro rata basis when the communication is a telephone call. The total charge is calculated based on the total call duration (e.g., the number of seconds or minutes consumed). In one embodiment of such a typical IN, the billing and / or control elements are programmed to provide subsequent quotas if the call continues beyond the initial quota. Alternatively, in another embodiment of such a typical IN, the initial quota may also be a final quota that, once exhausted, may result in the call being disconnected (released). For example, upon determining credit sufficiency based on the BCSM and based on the tariff associated with the requested call destination, identified by an address signal (e.g., a called party number (CdPN)), a processing element (e.g., a billing element / system) of the typical IN may use the initial service quota (e.g., the maximum allowed call duration) and instructions to continue handing over the call and routing it to the destination.

[0109] In addition, in a typical IN scenario, the control element can arm certain trigger detection points (TDPs) that may be encountered during the communication process in order to be alerted, such as, but not limited to, arming TDP-R (TDP as Request Armed), which, when encountered, suspends communication processing and waits for further instructions from the control element, or being notified, such as arming TDP-N (TDP as Notification), which simply notifies the control element when an event is encountered. In one embodiment, these trigger detection points can be statically armed and set in the user profile (e.g., in O-CSI).

[0110] In one embodiment, a typical control element of a typical IN can issue a request to report a BCSM event (RRBE) to notify when the original call is answered (DP O_Answer) and when the call is released (DP O_Disconnect) in order to control and / or monitor the call, thereby controlling billing in substantially real time and calculating a total charge to be charged based on the duration of the call. In addition, the control and / or billing element of the typical IN can be programmed to instruct the typical switching element to perform an application charge (ACH) function, wherein the typical switching element begins or continues to monitor the duration of the call, and when the initial quota is exhausted or when the call is released, the switching element can then provide an application charge report (ACR) to the typical control element. Upon receiving the ACR, the typical control and / or billing element can calculate a total charge based on the call tariff, which will be applied to the call by processing and generating a CDR (call data record).

[0111] Therefore, another technical problem to be addressed in the present disclosure is the lack of a technical solution that would allow a cellular device (e.g., a smartphone) to signal an operator of a cellular network (e.g., a typical IN billing element) to control / cause the process of recording / generating / applying charges (e.g., CDRs) applied to a call or service in an electronic data record associated with the cellular device.

[0112] However, another technical problem involved in the present disclosure is the lack of a mechanism to automatically call and / or cancel a transaction after it has been submitted.

[0113] However, another technical problem being addressed in the present disclosure is that many users may be trapped in duplicate subscriptions to services they did not intend to subscribe to and / or do not understand the implications or terms of the subscriptions because, for example, but not limited to, the terms of service are not clearly presented and / or articulated through Premium Short Message Service (PSMS) communications, as such communications do not technically indicate the resulting tariffs and charges. For example, in order for a typical IN network to apply differentiated billing rates, a typical IN network requires the use of alternative bearers and services, such as PSMS, in which short address codes are assigned to messaging services, which can then be associated and used to apply different rates, typically premium rates, to users using the messaging services. However, such Premium SMS (PSMS) rating elements of a typical IN are not programmed to recognize the short codes themselves as enumerations and triggers, indicating the resulting tariffs and charges. Therefore, one of the technical drawbacks of the PSMS rating elements of a typical IN is the need for metadata to be transmitted in the SMS body to communicate to the user the tariff that will be applied to the selected service. Typically, such metadata may not inform the user. Furthermore, another technical flaw in the typical PSMS model is that the desired tariff and charges to be applied are not communicated from the cellular device associated with the user / consumer, but rather by a third-party PSMS platform provider, which instructs the operator’s IN billing system what charges to apply based on the requested service, placing billing outside of the user’s control.

[0114] However, another technical issue being addressed in the present disclosure is that cellular billing originating from the internet, such as, but not limited to, direct carrier billing (DCB), may allow third-party charges for digital content and services to be charged to cellular accounts without providing control and transparency to the user and without originating from a cellular device associated with the user. For example, DCB can be viewed as an internet backdoor to the carrier's billing system, allowing transactions and therefore can be described as internet originated (IO) billing. For example, DCB uses a two-factor authentication (2FA) method (e.g., 2FA SMS) to authenticate a cellular device, which may send a one-time password (OTP) over the cellular network, which the user / customer is then required to resubmit back to the 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 described herein, the use of 2FA may create a number of technical drawbacks, such as the introduction of additional steps and / or clicks (e.g., six (6) additional clicks required to process a single 2FA, including, but not limited to: opening the SMS, entering a four (4) or more digit OTP in an internet application (IAPP), and then clicking submit). Furthermore, another technical flaw associated with 2FA SMS is the use of the SS7 messaging network, which may have inherent security vulnerabilities. For example, the SS7 signaling network could allow malicious actors with access to SS7 peers to redirect and / or intercept these mobile-terminated signals carrying authorization codes. Such security flaws associated with the use of 2FA over the SS7 signaling network can often arise from situations where the source of SS7 messages is not authenticated, allowing critical network control messages to be injected into the SS7 network from entities masquerading as cellular devices (e.g., mobile phones) and / or switching and control elements. For example, a malicious actor could simply inject and forge location updates for cellular devices (or similarly overwrite user profile information in the HLR, etc.), hijacking cellular routing to surreptitiously intercept phone calls and / or text messages.

[0115] For example, man-in-the-middle (MITM) attacks led the U.S. National Institute of Standards and Technology (NIST) to withdraw its recommendation and support for such 2FA services. Therefore, in at least some cases, while claiming to improve security, cellular 2FA can compromise security because anyone knowledgeable enough about exploiting SS7 vulnerabilities could be able to present another person's MSISDN (the MSISDN of a computing device (e.g., a cell phone, etc.) associated with another person), intercept the authentication code, and conduct illegal transactions on the now compromised (hijacked) cellular account.

[0116] Furthermore, while in at least some cases a cellular operator / carrier may be able to probe its network traffic to extract the device identity of a cellular device, for example, by inspecting the cellular data source IP (Internet Protocol) address and correlating a cellular data session identifier with cellular device ownership and identity data (e.g., MSISDN) stored by a network element, this approach has at least one technical drawback due to the requirement that users connect to the Internet over a mobile packet backbone network (MPBN) using a cellular packet data bearer, which would not be available to those using a Wi-Fi connection, where the source traffic does not necessarily travel over the cellular network and / or uniquely identifies the cellular device.

[0117] For example, another technical shortcoming recognized herein, at least in certain circumstances, is that once a cellular device is authenticated, DCB will typically utilize Premium Rate SMS messaging (PSMS), which can also be susceptible to abuse (e.g., security breaches, phishing attacks, etc.). For example, when a user selects the option to pay via cell / mobile phone (e.g., see FIG10 ), the DCB platform will typically send a text message to the user / consumer's cellular device, originating from a Premium Rate Short Code Address (the address of the DCB messaging platform). Typically, the SMS will include the transaction price within the body of the SMS message, which will be programmed to require the recipient (e.g., the consumer) to reply with an affirmative (e.g., "Y") to confirm the transaction.

[0118] Furthermore, another technical deficiency acknowledged herein is that when the DCB platform receives an SMS reply confirmation, the DCB platform may not be able to reliably determine that the SMS reply confirmation is being sent from a cellular device and that the DCB platform accepts and trusts the SMS reply confirmation as originating from the cellular device, and, therefore, express permission to complete a transaction on behalf of the consumer may be misplaced because the SMS reply confirmation itself may be corrupted by Trojans (malware) that intercept and respond in the background without alerting the consumer / user. Upon receiving the SMS reply confirmation to the PSMS, the DCB platform may be able to complete access actions by instructing a billing element of the cellular carrier / operator (e.g., a carrier billing system) to debit the transaction amount from a prepaid cellular account associated with the user's cellular device, or credit the transaction amount to a cellular account associated with the user's cellular device. As described herein, at least some of the technical deficiencies addressed herein are caused by numerous security vulnerabilities associated with one or more of the following steps of a typical DCB process:

[0119] 1) Users must manually select cellular bill as the payment method;

[0120] 2) Users must manually enter their mobile phone numbers (e.g., MSIDN), thereby exposing their mobile phone numbers (e.g., MSIDN) to third parties;

[0121] 3) The user must wait for the 2FA SMS code on their mobile / cell phone to verify their MSISDN;

[0122] 4) The user must switch the application context to open the received SMS and remember the one-time password (OTP) contained in it;

[0123] 5) The user must call up and manually re-enter the OTP into the internet service application screen;

[0124] 6) The user must then wait for PSMS to accept the transaction price;

[0125] 7) The user must manually reply to confirm the PSMS transaction amount; and

[0126] 8) Users may only use the content or access the services.

[0127] For example, even though the carrier network may utilize packet sniffing to verify cellular identity, the process will still utilize 2FA, which will still result in a cellular billing transaction sequence that may include twenty (20) manual keystrokes and clicks. Even if the cellular device has been authenticated, subsequent DCB transactions may still require at least six or more manual user-driven inputs. Furthermore, steps 6 and 7 above in the DCB protocol are typically required to meet regulatory requirements governing user opt-in and purchase confirmation when choosing to pay for third-party content and services against their cellular account.

[0128] Furthermore, another technical shortcoming is that, since the only detailed record of a transaction is the message content of the internet-originated SMS body, cellular carriers typically do not store and / or report this content in itemized billing (e.g., in account records). Furthermore, given that SMS reply confirmations can be unauthorized (e.g., hijacked by bad actors) and do not encapsulate and track the SMS transaction path (e.g., DCB transaction records are transient and flawed), typical cellular carrier / operator information management (IN) may be forced to rely on third-party metadata. For example, a cellular account may simply itemize / describe a DCB transaction as the SMS message that incurred the aforementioned premium cost, without providing authoritative and irrevocable cellular data records capturing the transaction amount confirmed by the user at the time of purchase. This incomplete billing record, at least in some cases, can result in numerous disputed DCB transactions being recorded on cellular accounts. Therefore, under third-party billing control, DCB is inherently vulnerable, requiring extensive fraud detection and prevention measures. Furthermore, such security measures often presuppose that users audit their bills and report suspicious transactions. As a result, many fraudulent DCB chargebacks go undetected and unreported, costing consumers billions of dollars in unauthorized transactions, with relatively small amounts going undetected and affecting millions of unsuspecting online users, a practice known as skimming.

[0129] However, another technical problem to be solved in the present disclosure is that users are now generally required to provide their mobile phone numbers in plain text without any encryption in order to provide 2FA codes to verify the mobile phone number and to register and access services (e.g., Meta, Twitter, Signal, etc.). TM (Signal Messenger LLC.) Facebook TM and WhatsApp TM ), TM etc.), which may compromise privacy and / or security. For example, since 2FA is premised on sending a mobile terminal (MT) signal to the relevant device, which necessarily requires the cell ID (e.g., MSISDN) to be revealed in plain text in order to address the user and transmit a one-time password (OTP) to verify their cell ID, the 2FA system stores and potentially exposes millions of real digital identities (mobile phone numbers) to data breaches and / or other activities (e.g., spam, phishing), and may allow internet companies to share users' PI with third parties without the user's knowledge, control, and / or consent.

[0130] However, another technical problem being addressed in this disclosure is that users who wish to avoid providing their mobile phone numbers for registration may be able to purchase fake or "burner" phone numbers. Typically, the fake phone number is used once: after the user receives a verification code, the number ceases to exist or is reassigned to another user.

[0131] However, another technical issue addressed in the present disclosure is that there are electronic services, such as but not limited to those provided by companies such as PVACreator (www.pvacreator.com), which may utilize bots to automatically register and generate fictitious accounts in bulk, which may be related to other bots, for use in online services and social platforms.

[0132] Another technical drawback is that digital content publishers who wish to monetize their content may seek to attract their users to recurring weekly, monthly, or annual subscriptions, as charging for any shorter subscription period or for any smaller amount of content is generally not technically beneficial to online content providers, as it may require a more complex technical setup and maintenance of electronic / digital resources. This includes access-restricted electronic / digital resources with associated fixed costs, which would make electronic access impossible on a per-SSU basis and prohibitive for users / consumers / entities who do not possess the technological sophistication and / or are unable to build the required technical infrastructure. For example, individual and small entity content creators are often forced to aggregate their works through content curators and aggregators, who might pay composers a meager fee of $0.00001 (1000 cents) per track on a music streaming service.

[0133] Another technical shortcoming of digital subscription technology is that paywalled digital subscriptions typically have only single-digit conversion rates (according to a survey conducted by Digiday(TM), only 5% of people subscribe) due to the lack of sufficient technology-driven interactive experiences to convert and retain users. As a result, subscription-based services are heavily skewed towards large national and multinational news media and content producers due to their large base, further undermining the democratization of digital publishing.

[0134] Another example, which has long existed for at least the past three decades without addressing the technological development needs associated with the current disclosures, but is identified without restriction is micropayments, redacted (Ryan Shea,

[0135] medium.com / radartech / micropayments-abridged-2f110302677c): “A functional micropayment system, enabling instant, tiny transactions for under a dollar, is widely considered the holy grail of web monetization. … In the past, fundamental issues related to usability, psychology, and economics have been overlooked. These issues must be addressed for micropayments to succeed.”

[0136] Another example, at least for the past thirty years, of the long-standing but unresolved need for technological development related to current disclosure is identified unrestrictedly by Babbage of the Web (Ted Nelson, The Economist, December 7, 2000): “…he hoped that publishing would be democratized, with readers paying only for what they read, and the authors of the most popular literature rewarded accordingly.

[0137] Another example, which has long existed for at least the past three decades but has not yet addressed the need for technological development relevant to the current disclosure, is Peppercoin micropayments (Ronald L. Rivest, Proceedings Financial Cryptography, 2004): "We believe that the introduction of efficient micropayments into the world of internet e-commerce may be as significant as the invention of metal coins by the Lydians in 640 BC".

[0138] Another example of a long-standing, but unresolved need for technological development relevant to the current disclosure, which has existed for at least the past three decades, is identified as, 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 web’s founders fully expected some form of digital payments to become integral to its functionality. But nearly three decades later, we’re still waiting. … In the absence of a digitally native micropayment system, content creators have been forced to rely on advertising to support themselves. This has been a losing game for all but the largest players. Even the clear winners of the digital advertising economy—Facebook and YouTube—must operate at scale, with extensive monitoring and minimal human oversight of their systems to make ad financing work. Content creators are left chasing eyeballs and ad fees on these giant platforms, whose business models favor virality, misinformation, and outrage. … As if all this weren’t bad enough, invasive and bloated ad tech layers slow the internet and serve as potential vectors for malware. Moreover, the online advertising business is rife with click fraud; the whole thing could be a house of cards.”

[0139] However, another technical issue addressed in the present disclosure is that typically, and often necessarily, electronic exchanges that conduct transactions in fiat currencies are centralized (CeFi - centralized finance), require tool and / or wallet disclosure, and are therefore vulnerable to cyberattacks from malicious actors (e.g., phishing, spam, etc.). Therefore, in some embodiments, a simple, fast, and secure method may be desired.

[0140] However, another technical issue addressed in the present disclosure is the fraudulent use of stolen credit / debit cards (collectively referred to herein as "financial instruments"), for example, in online transactions, which can cost the industry and consumers significant amounts of money in risk management surcharges, levies, and insurance. For example, a typical artificial intelligence (AI)-based fraud detection system can identify transactions that appear fraudulent or suspicious, which may actually be legitimate transactions, and may then be initially declined, pending consumer approval (e.g., a text message fraud alert is sent to the cardholder's mobile phone, requiring a yes / no verification response) to allow the transaction. The legitimate customer may then be required to pause (e.g., wait a few minutes) before submitting a second, repeat transaction. A typical AI system may not be able to predict legitimate purchases, albeit unusual ones.

[0141] Some illustrative, non-limiting technical solutions described herein include access control network architectures and systems having cellular network components and elements modified to a host access control mode designed to translate and / or facilitate cellular communication signals according to a novel cellular communication protocol with multi-part multi-function address signaling, and methods of using the same.

[0142] 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 issues identified herein by utilizing an access control network architecture and system having cellular network components and elements, such as, but not limited to, control and / or billing elements, modified to host access control mode, designed to convert and / or facilitate cellular communications signals conforming to a novel cellular communication protocol with multi-part, multi-function addressing, and methods for using the same. In at least some embodiments, the access control mode of the present disclosure can be designed to process mobile source address signals transmitted / transmitted in accordance with the novel cellular communication protocol (also interchangeably referred to herein as the STAR Band signaling protocol), wherein the signals have multi-part, multi-function address signaling, including multiple address signal parts designed for multiple functions. The various modes (e.g., sequences, strings, headers) of the multi-part, multi-function address signaling can be collectively referred to herein as the "STAR Cellular Access Control Protocol / Code / Policy."

[0143] In at least some embodiments, as described below, an illustrative multi-part multi-function address signaling sequence (also interchangeably referred to herein as a STAR band signaling sequence) is transmitted by a computing device having cellular signaling capabilities (e.g., Figure 1 The device 100) transmits / transmits, for example, but not limited to, when a user dials and / or sends a text message (via a computing device), such a multi-part multi-function access control sequence is displayed to the user and may include at least three parts (considered starting from the first address signal in the address signal sequence), Part-1 / Part-2 / Part-3, which are designed to serve at least three respective different functions:

[0144] Part 1 aims to provide the first function.

[0145] The second part (Part 2) is intended to provide a secondary function, and

[0146] The third part (Part 3) is intended to provide a third function.

[0147] It should be understood that the symbol " / " in the above notation is used merely as a logical separator between the parts of the above illustrative multi-part multi-function access control sequence, and that the parts may be dialed in sequence without separator signals or may be typed in sequence (e.g., as an address for cellular communication (e.g., call, text message, etc.). In at least some embodiments, at least two of the first function, the second function, and the third function are different. In at least some embodiments, the first function, the second function, and the third function are different.

[0148] In at least some embodiments, but not limited to, the first part (Part-1) may include an address signal corresponding to at least one symbolic routing prefix (e.g., STAR("*")), so that, serving the first function (i.e., network routing function), the elements (nodes) of the cellular network may be programmed to recognize as the symbolic network routing prefix and route the entire multi-part multi-function address signaling sequence or the modified / parsed multi-part multi-function address signaling sequence (e.g., a subsequence consisting of Parts 2 and 3, a subsequence consisting of Part-2, a subsequence consisting of Part-3, a derived subsequence derived from at least one of Part 1, Part 2, or Part 3) to at least one network destination, such as, but not limited to, a computing platform that may be configured to have at least the following functions: Figure 2 The access control platform 210 and / or Figure 26A The STARKEY platform and other figures in this article.

[0149] In at least some embodiments, the illustrative multi-part multi-function address signaling sequence can correspond without limitation to, for example, but not limited to, the order of calling the multi-part multi-function access control sequence (for example, the user dials using a local cellular phone APP, or the user grants the local cellular phone APP permission to dial, for example, with a click-to-call function) and / or the target address of the text message, including Part-1 / Part-2 / Part-3, in the format of: *NNNXYXYXYXYXYXY, where the asterisk (*) corresponds to the address signal containing Part 1, NNN corresponds to the address signal containing Part 2, and XYXYXYXYXYXY corresponds to the address signal containing Part 3. In at least some embodiments, reference to signaling sequences / strings for a user to manually dial various addresses is illustrative because multi-part signaling sequences can be automatically entered and dialed (e.g., with a click-to-call feature, or via programmable SMS text messaging, etc.), and it will be understood that the same or sufficiently similar operating and communication principles also apply when a user enters a multi-part multi-function access control sequence as a dialed target address or SMS target (e.g., user input using an SMS messaging application), particularly when the cellular-enabled device is different from the computer device (e.g., a laptop, a terminal without cellular signaling capability).

[0150] In at least some embodiments, the illustrative multi-part multi-function address signaling sequence may correspond, without limitation, to an address sequence (e.g., a cellular phone address, an SMS address) of an illustrative multi-part multi-function access control sequence, comprising Part 1 / Part 2 / Part 3, in the format:

[0151] Figure 1 Routing symbol / access code / Figure 26A and 26B The RAN sequence,

[0152] It should be understood that the symbol " / " in the above symbols is used only as a logical separator between the parts of the above illustrative multi-part multi-function address signaling sequence, and that the parts can be dialed in sequence without the separator signal.

[0153] In at least some embodiments, the illustrative multi-part multi-function access control sequence described above may be presented as part of, for example, but not limited to, Figure 1 The access controller interface element 103 as part of the process of accessing restricted resources, or Figure 26A As part of the access and authentication process, Star Challenge 2603 is communicatively coupled to, for example, a cellular network control module 121 of FIG. 11 , which may be part of a cellular network (e.g., a typical IN billing element). Thus, when a mobile-originated cellular communication protocol is activated by a cellular service-enabled computing device (e.g., a cellular / mobile phone) to send / issue an access request including the illustrative multi-part multi-function address signaling sequence described above, corresponding to a multi-part multi-function access control sequence, along the Figure 1 In the cellular signaling path 105, the cellular network managed access control scheme 121 can sequentially identify the illustrative multi-part multi-function access control sequence of Part 2 above, also interchangeably referred to herein as "MICROBAND," as a rate applied to at least one of a call, a product, or a service, thereby controlling / causing an electronic data record (e.g., a data record in the cellular wallet 490 of FIG. 4 (e.g., a prepaid account associated with a SIM card)) to be associated with a cellular service-enabled computing device (e.g., a cell phone / mobile phone) and / or controlling / causing a corresponding amount to be deducted from the cell phone wallet. In at least some embodiments, Part 2 of the illustrative multi-part multi-function access control sequence can correspond to one or more minor units (e.g., one or more cents, etc.) of one or more currencies defined by the ISO 4217 standard.

[0154] In some embodiments, for example, reference Figure 1, for example, but not limited to, after the cellular network control scheme 121 performs or causes to be performed actions associated with the desired function 2 of the illustrative multi-part multi-function address signaling sequence, Figure 1 The cellular network control scheme 121 and / or one or more cooperating network elements may be programmed to route / transmit the entire or at least a specific portion of an illustrative multi-part multi-function address signaling sequence corresponding to and including part 3 (e.g., part 2 associated with part 3, only part 3) of a multi-part multi-function access control sequence and, for example, but not limited to, at least one identity associated with a cellular service-enabled device (e.g., an MSISDN) to at least one remote destination, for example, but not limited to Figure 1 The remote Internet access control server 111 or STARKEY platform is detailed, for example Figures 26A-28 , and other figures in this article.

[0155] In at least some embodiments, MICRO BAND (Part-2) address signaling may be formatted to support a zero charge option, which may be signaled and recorded in the cellular CDR (certificate):

[0156] *000RAN (where RAN is the 3rd part).

[0157] In at least one non-limiting embodiment, zero microband signaling can allow for at least one of the following: reversal of a bill, reversal of a payment authorization, issuance of a credit (e.g., a company pays micro-fees / tabs for all of its users). For example, in at least one non-limiting embodiment, utilizing the functionality of a mobile operator's zero microband signaling and / or reverse billing data service can allow a website or URL owner to cover the cost of data used by visitors to their website so that consumers can visit, browse, and / or transact with the website and / or advertisements without incurring charges on their cellular account balance - including enabling customers to access the website without any airtime / data balance. For example, in at least one non-limiting embodiment, utilizing the functionality of a mobile operator's zero microband signaling and / or reverse billing data service can allow, without limitation, reverse billing SMS messaging, where the cost of replying to an SMS is charged to the business sending the message rather than the consumer being asked to reply to the SMS.

[0158] In at least some embodiments, part-3 of the illustrative multi-part multi-function access control sequence may include a randomly generated sequence of numbers and sequences, a Star Random Challenge (e.g., RAN) and processed at at least one remote destination to perform or cause performance of an action associated with the desired function, such as, but not limited to, a Star Random Challenge and Response, as described in detail herein.

[0159] In at least some embodiments, Part 3 may include a randomly generated sequence of numbers (e.g., The StarChallenge (e.g., RAN)) that the access control platform generates and processes as described herein. In at least some embodiments, the randomly generated sequence of numbers for Part 3 may be generated based on a logarithmic function where the exponent is the product of the length of Part 3 (X number of bits) (e.g., 10^X), interchangeably referred to herein as a "logarithmic band."

[0160] In at least some embodiments, various aspects of the creation, processing, utilization, transmission, and / or modification of the illustrative multi-part multi-function access control sequence (including Part 1 / Part 2 / Part 3) can be performed according to 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, a signal can be determined according to the following non-limiting logic:

[0161] If the total received 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 plus a RAN signal containing, for example, 15 digits), then such signal may be referred to interchangeably herein as a "MACRO BAND" signal. For example, in a non-limiting embodiment,

[0162] The macro signal can be calculated as shown in the following cases:

[0163] ((STOTAL>SMICRO)&(STOTAL <SRAN))。

[0164] In at least some embodiments, the exemplary signaling code to rate conversion can be performed by, for example, referencing the SIP URI / ToString header and performing string operations to parse each part of the illustrative multi-part multi-function access control sequence, as shown in the following JavaScript code showing parsing Part-2, corresponding to the exemplary fixed three-digit notation (NNN), and knowing the specific exemplary STAR BAND signaling protocol, as shown in Table 1:

[0165] parseInt(SIP_To.substring(1,4)).

[0166] Table 1.

[0167]

[0168]

[0169] For example, but not limitation, assuming that the address signals of the illustrative multi-part multi-function address signaling sequence correspond to a multi-part multi-function access control sequence of S (e.g., S=*099927485617253), then appropriate substring extraction and integer conversion functions, as detailed herein and performed by, for example, an MNO billing element, can extract the "099" and convert these MICRO band signals (e.g., from string to integer format) into a matching $0.99 charge (e.g., as a CDR), as disclosed herein.

[0170] In one non-limiting embodiment, the MNO element can use a wildcard routing entry in the network switching element table to route all undefined star dialing (e.g., "*" prefix) numbers to the STARKEY access control platform, while enabling the network billing element to extract the MICRO band signaling for charging purposes, and all additional signals (e.g., part 3) are located to the right of the MICRO band signal and can be transparently transmitted to the STARKEY access control platform for internal calculations without the need for MNO interpretation.

[0171] The various string and number manipulations disclosed herein (which may be collectively referred to herein as the "STAR Cellular Access Control Protocol / Code / Policy") may thus, in at least some embodiments, allow an MNO element to provide dynamic billing to the Internet, where, for example, but not limited to, the disclosed buttons remotely control core MNO processes (e.g., the MNO billing program).

[0172] In at least some embodiments, the second and third parts of the multi-part multi-function access control sequence of the present disclosure may be further separated using one or more symbols (e.g., "*", "#", etc.), but not limited to the following:

[0173] 1. *099*099927485617253 (*Part 2*Part 3)

[0174] 2. *000*099927485617253 (*Part 2*Part 3)

[0175] 3. *9999*099927485617253 (*Part 2*Part 3)

[0176] 4.*099#099927485617253(*Part-2#Part-3), etc.

[0177] The above illustrative patterns can provide visual and computational markings that separate multiple portions of signaling bands according to the STAR cellular access control protocol / code / policy, and also allow for signaling implementations of fixed length, variable length, or both, which can be used to provide dynamic resource access for multi-resource authentication and authorization, including dynamic charging.

[0178] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by leveraging microwave band and / or macro band communications between multiple (e.g., 2, 3, 5, 6, N, etc.) cellular wallets. In at least some embodiments, a user may dial (and / or send an SMS or USSD) a notational routing prefix to a number enumerating a MICRO BAND followed by a number enumerating a MACRO BAND, the former being, for example, but not limited to, immediately deducted from their cellular wallet, the latter being, for example, unlimited, as detailed herein, transferred from a sender internet wallet to a recipient internet wallet, wherein the sender computing device has been authenticated by, for example, one or more methods detailed herein, which may result in the identity of the sending device being stored in an internet application (e.g., an IAPP, a browser, etc.), thereby allowing the systems / components / elements / devices of the present disclosure to utilize multi-part microwave band (NNN) / macro band (XXX) address signaling.

[0179] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by utilizing, for example, but not limited to, mobile-originated FLASH HOOK signaling, wherein communications can occur on sub-second calls that connect and disconnect instantaneously, and in one non-limiting embodiment, session tickets (e.g., CDRs) are generated at the originating mobile switch in a number equal to the MICROBAND address signal (digit).

[0180] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more technical problems identified herein by utilizing, for example, but not limited to, the disclosed illustrative permission-based communication protocol, which can be configured to uniquely synchronize and correlate such Flash Hook cellular communication session events, addressing the recipient using a second Internet wallet, thereby seamlessly and securely switching digital tokens (e.g., digital assets representing fiat currency) in a peer-to-peer signaling communication session, over a time-efficient (e.g., nanosecond, millisecond, microsecond, etc.) signaling protocol, using fewer computing and / or network resources, at a marginal cost.

[0181] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by utilizing an illustrative Star TAP communication signaling protocol, using a permissions-based control architecture hosted in the cloud, for use by friends and family, for example, but not limited to.

[0182] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by utilizing an illustrative TAP communication signaling protocol that can provide nanocellular (i.e., down to a single cellular phone) ATM-style communication sessions in the form of a social media-type network, whose functionality allows users to redeem Star digital assets, such as but not limited to fiat currency, and further settle, for example, invoices (i.e., digital receipts) for online and / or real-world goods and / or services provided in formal and informal sectors (e.g., housework, home repair, babysitting, etc.).

[0183] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by utilizing an illustrative Star TIP communication signaling protocol that can be configured to enable any service provider, in the formal and / or informal sectors, to accept Star currency / tokens that may be earned through a variety of means, such as, but not limited to, performing online activities disclosed herein (e.g., digital content distribution), as tips simply by displaying an Internet QR code directly linked to their Star Internet wallet address (e.g., MSISDN-B).

[0184] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to allow users to digitally receive campaign alerts, such as, but not limited to, physical deliveries of goods and / or services that may be created by online marketplaces (e.g., FedEx, UPS, Uber Eats, Uber, Lyft, Craig's List, etc.), by utilizing an illustrative so-called digital / virtual Star "tip jar" (Star Internet Wallet) addressed to the recipient's cellular number (i.e., MSISDN, hashed cellular identifier XYM4, etc.).

[0185] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by utilizing an illustrative Star INV (invoice) and communication signaling system, network architecture, and method to enable any service provider to accept Star currency / tokens for instant invoice settlement capture and / or satisfaction / recording, directly switching between Star Internet Wallets, which can be created to instantly accept and / or record electronic activities (e.g., electronic payments / transactions) without any registration procedures, simply by addressing and directing payments to a mobile phone number (e.g., MSISDN, XYM4, etc.), encapsulated in one embodiment, in a QR code (e.g., URL encoded).

[0186] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by utilizing illustrative Star TAP, TIP, and INV protocols, which can be configured to use personalized payment URLs (PURLS) and / or QR codes to provide frictionless acceptance of communication sessions (e.g., payments) based on novel mobile communication addressing signaling and related activities as disclosed herein.

[0187] As described herein, at least some embodiments of the present disclosure may utilize one or more of the described embodiments to enable P2P (peer-to-peer) communication sessions that may involve, but are not limited to, payment and / or transfer of digital tokens (e.g., digital assets representing fiat currency).

[0188] Illustrative non-limiting embodiments of cellular systems whose elements are modified to translate and / or operate cellular communication signals according to a novel cellular communication protocol and network architecture utilizing a cellular network managed access control model, and methods of use.

[0189] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by utilizing specific programming elements of a cellular network, such as control and / or billing elements. In some embodiments, the control and billing routines may be programmed to be executed by the same element of the IN.

[0190] For example, as discussed herein, one technical shortcoming of a typical IN is that an operator / carrier can only apply a single published tariff to a single category of calls (e.g., unlimited international calling tariffs, tariffs for domestic calls by country / region, tariffs for on / off network domestic calls, tariffs for fixed-line terminated calls, tariffs for mobile terminated calls, etc., where such tariffs themselves may be further differentiated, for example, by the user / customer's service agreement, profile, or time of day). Furthermore, another technical shortcoming of a typical IN is that if unlimited calling could be offered to certain call categories in exchange for a fixed subscription fee, calls could be metered without necessarily incurring additional charges.

[0191] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network that can be specifically programmed to overcome, for example, but not limited to, the technical drawback of having a single published rate applied to a single class of calls, by allowing multiple billing rates to be applied to a single class of calls, for example, multiple rates for star calls (calls prefixed with an asterisk). In one embodiment, such multiple rates are achieved by pre-populating a rating table that is stored in a non-transitory memory of a specific programming element for a specific cellular network (e.g., IN) with amounts that directly map and match address signals of symbol prefixes that enumerate and encapsulate the desired billing rates. In such an embodiment, a discrete (fixed) number of rating table entries can be populated to define a set of desired tariffs, as tabled and described, for example, without limitation, in Figure 15B middle.

[0192] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by utilizing one or more elements of a cellular network (e.g., a carrier's billing system and rating engine) that can be specifically programmed to support the signaling of the present disclosure in order to dynamically determine applicable rates by calculation, for example, but not limited to, by parsing a symbol-prefixed address signal into an integer format that is then equivalent to a monetaryly appropriate and applicable billing charge (e.g., applied to a CDR). For example, converting an address signal string "*NNN" to the integer format "NNN" is equivalent to, for example, NNN cents to be recorded in a user's cellular 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 to enumerate a substring of the billing charge in order to calculate the appropriate integer value and currency, as described below, for example, with reference to Figure 15B .

[0193] For example, prior to the present disclosure, if a user of a cellular device dialed, for example, "*009" on a keypad, the user would hear an error voice message such as "We cannot complete the call" because the carrier would lack the necessary billing intelligence and routing modifications disclosed herein. In contrast, as detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that aim to exploit such network anomalies (errors) by reprogramming the network with new logic to successfully service and support such star calls, thereby enabling micro-charges directed by mobile devices, as disclosed herein. For example, such network error messages can be resolved by programming one or more elements of the cellular network (e.g., control elements of the IN (e.g., SCP / SCF, billing elements of the IN (e.g., OCS)) to process the sequence of "*009", for example, to parse out "009" as a monetaryly appropriate rate, for example, nine (9) cents, and to create or instruct the creation of a corresponding CDR in the amount of nine (9) cents, applied to an account associated with the cellular device, and then routing the communication to a service access control platform (e.g., a star node or DCB of the present disclosure) to complete the relevant Internet transaction.

[0194] Notably, as detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to achieve this 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 of the IN (e.g., OCS)) that can be specifically programmed to apply tariffs in a flat rather than proportional manner. That is, regardless of the duration of a call, a fixed fee is charged in accordance with the definition of the call tariff, rather than a variable fee.

[0195] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein by utilizing (but not limited to) a HOOK FLASH approach that intentionally limits calls to very short durations (e.g., one second) such that a fixed-fee billing agreement can be programmed to rate rates per minute rather than per second.

[0196] Thus, in contrast to the detailed technical deficiencies described above in connection with typical PSMS approaches, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to be transparent to the user / consumer in that the address signal (e.g., dialed digits) directly equates to the tariff and billing charges to be recorded, in a one-to-one relationship (i.e., “you dial is what you pay”).

[0197] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that aim 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 / charging / payments, such as, but not limited to:

[0198] i) limit the maximum transaction amount,

[0199] ii) remove the extra payment confirmation step,

[0200] iii) does not allow recurring subscriptions, only supports SSU, and

[0201] iv) Elements that automatically switch small value payments to the cellular network (e.g. cellular billing systems).

[0202] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that address one or more technical issues related to the inability to automatically reverse transactions once they have been submitted, such as, but not limited to, creating a transparent and sustainable process with sufficient transaction details in the records of cellular carriers / operators to reduce or eliminate the burden of charge reversals on electronic payment processors, at least in part for practical, psychological, and financial reasons, allowing for solutions and / or circumvention of heretofore unsolvable problems. For example, by limiting maximum transactions to small (micro) amounts, the systems and methods disclosed herein avoid the need to process reversals and refunds of such single-service-unit (i.e., discrete) transactions because they are deemed financially insignificant and psychologically insignificant.

[0203] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to leverage one or more elements of a cellular network (e.g., a control element of an IN (e.g., SCP / SCF), a billing element of an IN (e.g., OCS)) that can be specifically programmed to allow the cellular network to leverage the cellular telephone network for high-frequency activities, such as, but not limited to, micro-billing billions of existing mobile (e.g., cellular) wallets (e.g., digital account records of mobile communication companies / entities) holding trillions of dollars in digital airtime currency to provide a seamless, frictionless, and trusted digital experience associated with online digital content and / or services (e.g., but not limited to). For example, as detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to leverage one or more elements of a cellular network (e.g., a control element of an IN (e.g., SCP / SCF), a billing element of an IN (e.g., OCS)) that can be specifically programmed to allow the cellular network to provide micro-commerce capabilities (e.g., digital transactions involving, for example, but not limited to, one or more minor units (e.g., one or more cents, etc.) of one or more currencies defined by the ISO 4217 standard).

[0204] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to utilize cellular networks (mobile phone networks) for software licensing by leveraging one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to translate and / or operate cellular signals according to new communication protocols and network architectures, for example, by, but not limited to, allowing users to secure (e.g., purchase) application time just as one currently secures (e.g., purchases) mobile (e.g., cellular) airtime, renting applications for short periods of time (e.g., minutes, an hour, a few hours, a day, a few days, etc.) rather than paying higher perpetual monthly licensing fees for infrequent usage, thereby, but not limited to, allowing users to precisely control what, when, and how much they consume, rather than being force-fed unwanted digital advertisements and locked into recurring digital subscription surcharges.

[0205] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to provide users with an enhanced sense of privacy and / or trust in digital online experiences / transactions / interactions, that their data is secure, and that their privacy is protected, by leveraging one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures.

[0206] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to enable low-cost, highly scalable micropayment activities / transactions / interactions by leveraging one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to novel communication protocols and network architectures to allow transactions of micro-currency values ​​(minor currency units) to be processed, to perform low-cost, highly scalable micropayment activities / transactions / interactions, directly switching within the dial-up flow.

[0207] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to enable micro-billing to be performed within a short period of time (e.g., milliseconds) of mobile-originated signaling issued during the call setup phase by leveraging one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a billing element of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures, which can comply with switching logic and one or more billing rules that may be defined by an Original Basic Call State Model (OBCSM).

[0208] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to enable telephone calls to be made via a Basic Call State Model (BCSM) having standardized call points (PICS) and trigger detection points (TDPs) and / or initial filtering criteria (IFCs) and service trigger points (STPs) by utilizing one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to a novel communication protocol and network architecture to allow telephone calls to be made via a Basic Call State Model (BCSM) having standardized call points (PICS) and trigger detection points (TDPs) and / or initial filtering criteria (IFCs) and service trigger points (STPs) that together define sequential steps in which the presently described network logic can be applied during initial call establishment and ongoing call state management. For example, but not limited to, one or more communication protocols detailed herein may utilize the finite state machine features of the BCSM and PICS to allow a switching element (e.g., an MSC) configured as detailed herein to interact with one or more control and billing elements of a cellular network (e.g., an intelligent network node in accordance with the ITU-T Q.1200 series of Recommendations (International Telecommunication Union)), in particular to perform / execute one or more authentication, authorization, and / or accounting (AAA) procedures, provide bill verification, real-time account balance management, and call progress monitoring, as detailed herein.

[0209] In some embodiments, during one such billing verification step, the requested call may be placed on hold to determine whether the account associated with the caller has sufficient credit to proceed and complete the call. That is, to determine whether the call can be allowed to advance and mature to a ringing state and be answered. Similarly, one or more communication protocols detailed herein may involve one or more billing systems utilizing a rating engine and / or table, as well as call data recording (CDRS), which can record transactions and apply charges on the digital network.

[0210] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to quantify the monetary value of communications 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 of the IN (e.g., OCS)) that can be specifically programmed to convert and / or manipulate cellular signals according to a novel communication protocol and network architecture so as to quantify the billing of communications by encapsulating discrete charges themselves in address signals (e.g., a number of decimal digits) so that the dialed telephone address of the communication enumerates the actual cost of the communication and, accordingly, the billing charge is applied to the carrier / administrator / operator's data records (e.g., a database) associated with the cellular network.

[0211] In some embodiments, one or more of the novel communication protocols detailed herein are designed to configure / modify / utilize various components of a cellular communication network to allow for quantification of the monetary value of a communication, and thereby quantification of the billing of the communication, by encapsulating the rate itself within a message (e.g., SMS) address signal (e.g., a decimal number) such that the communication address enumerates the actual cost of the communication.

[0212] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to provide technical transparency to related activities by leveraging one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and uniquely map dialed digits to monetaryly appropriate digits (e.g., on a rating table lookup) in order to provide technical transparency to the related activities by, for example, clarifying and highlighting the cost of the actual dialed digits.

[0213] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to avoid the lack of transparency and traceability to users that may be caused by the ability of third-party platforms to unilaterally withdraw funds from accounts associated with cellular users, which accounts would be associated with one or more technical issues discussed herein, by leveraging one or more elements of the cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that may be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures.

[0214] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to overcome this cellular authentication disintermediation and the resulting security vulnerabilities by leveraging one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or manipulate cellular signals according to novel communication protocols, such as, but not limited to, the mobile (cellular) originated HOOK FLASH signaling protocol disclosed herein, to transparently access the billing system of the mobile (cellular) network through the operator's "front door, so to speak" by leveraging the AAA (Authentication, Authorization, and Accounting) protocol in mobile originated (MO) phones.

[0215] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to uniquely and securely capture transaction costs in address signals emitted by cellular devices by leveraging one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or manipulate cellular signals according to new communication protocols and network architectures, and to a priori and authoritatively generate native cellular billing certificates (CDRs) to irrevocably capture and record transaction data according to one or more disclosed communication protocols, such as, but not limited to, the HOOK FLASH transaction protocol.

[0216] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to facilitate the use of cellular network services by utilizing one or more elements of the cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed and / or instructed to transparently timestamp all transactions and record the transaction consistent with (for example, but not limited to) any other telephone call, showing the address dialed as well as the duration and enumerated cost of the call, substantially at the time of the transaction, and possibly directly associated with a cellular device call record (e.g., the most recent call). For example, a transaction managed in accordance with the present disclosure may result in the following itemized mobile phone bill entry, as shown in Table 2:

[0217] Table 2.

[0218] Date and Time dial period cost 2021 / 10 / 01 10:30:15 *010 00:01 $0.10

[0219] In some embodiments, the present disclosure contemplates that typical credit card processing is based on two transaction states:

[0220] 1) Card presence and

[0221] 2) Card does not exist.

[0222] For example, "card present" typically describes more than just the physical presence of a credit card, as a transaction is considered "card present" only if electronic data is captured at the time of the transaction. For example, data can be captured by swiping a magnetic stripe card, dipping an EMV (Europay(TM), MasterCard(TM), and Visa(TM)) chip card, or tapping an NFC (Near Field Communication) or contactless digital wallet using a card stored in a smartphone (e.g., Apple Pay(TM)).

[0223] For example, a DCB originating over the internet and failing to capture cellular transaction data audit trails may be classified as a "card not present" transaction in typical credit card payment processing. Typically, even if the customer physically presents their card at the time of the transaction, all payment methods are considered "card not present" if no electronic data can be captured when the credit card is present. Given the inherent system vulnerabilities in card-not-present transactions, addressing these vulnerabilities is inherently more costly to mitigate fraud.

[0224] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to enable cellular communications by utilizing one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures in order to utilize, for example, but not limited to, local and core billing paths applicable to cellular telephone calls, for example, by employing, for example, but not limited to, the disclosed HOOK FLASH (WINK) protocol, which is securely underwritten and based on the presence of an active SIM card and internal data recording.

[0225] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to avoid the requirement for users / consumers to create and manage digital wallets in order to conduct transactions by utilizing one or more elements of the cellular network (e.g., the control elements of the IN (e.g., SCP / SCF) and the billing elements (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures, and they do not require the operator / carrier to expose internal elements of its operator IN (e.g., core billing system) to external third parties (e.g., DCB platform providers), thereby maintaining the integrity and / or security of the cellular wallet by conducting unique and synchronized internal transactions along the cellular phone billing path.

[0226] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to leverage one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures to provide fundamentally more secure and simplified mobile-originated (MO) authentication and transaction operations that may not require any manual data entry by the user and include micropayments (e.g., pence instead of pounds) that are automatically directed through elements of the cellular network (e.g., billing platforms). For example, based on the novel communication protocols and network architectures described herein, in some embodiments, the DCB access control platform of the present disclosure can be programmed according to one or more of the principles described herein to address and satisfy mass market adoption and demands, such as, but not limited to:

[0227] i) Limit payments to a maximum micro-threshold amount;

[0228] ii) automatically select and display the cellular bill as the single payment method;

[0229] iii) abandoning competitive periodic subscriptions for individual units of service, and

[0230] iv) Removal of additional verification and / or validation steps.

[0231] Furthermore, based on the novel communication protocols and network architecture described herein, in some embodiments, the DCB access platform of the present disclosure (e.g., the STARKEY platform) can be programmed to execute according to one or more of the principles described herein to extend beyond gaming to facilitate payments in the broader mass content distribution and consumption market. In some embodiments, limiting payments to micro-amounts may also cleverly circumvent regulatory spending restrictions and requirements, as transactions may now be limited to small change. Furthermore, by eliminating the vulnerabilities and friction introduced by 2FA and multi-step PSMs, a DCB platform reprogrammed according to one or more of the presently disclosed principles can now offer a ubiquitous and exceptionally streamlined payment process that has heretofore been unattainable. For example, without limitation, and as further detailed herein, in some embodiments, a DCB platform reprogrammed according to one or more of the presently disclosed principles can operate based on the following simplified instruction set and simple sequence of events, conducting transactions within a single digital payment and interface channel (e.g., STAR BAND):

[0232] 1. The user clicks the cellular micropayment button to display the purchase amount of the relevant access-restricted content / service;

[0233] 2. The cellular network (e.g., IN) determines the cellular device identity of the cellular device;

[0234] 3. The DCB platform charges the account associated with the identified cellular device; and

[0235] 4. Users can immediately access products and / or services.

[0236] Furthermore, in some embodiments, when the MPBN is not an active data carrier, resulting in the cellular network being unable to internally identify the cellular device, the IAPP may automatically engage, for example, but not limited to, a random challenge system / engine, to enable any network to seamlessly and securely identify the cellular device. For example, in at least some embodiments, the cellular device may have been previously identified, and that identification (e.g., MSISDN) or a uniquely derived identification (e.g., a cryptographically hashed MSISDN) may have been communicated to the IAPP.

[0237] In some embodiments, the exemplary computer-based inventive system / platform, exemplary computer-based inventive device and / or exemplary computer-based inventive component of the present disclosure may be configured to securely store and / or transmit data (e.g., identity, cellular identity, IMSI, MSISDN) by utilizing one or more encryption techniques (e.g., private / public key pairs, Triple Data Encryption Standard (3DES), block cipher algorithms (e.g., IDEA, RC2, RC5, CAST, and Skipjack), cryptographic hash algorithms (e.g., MD5, RIPEMD-160, RTR0, SHA-1, SHA-2, Tiger (TTH), WHIRLPOOL, RNG).

[0238] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to utilize a trusted network (e.g., a cellular network, IN) and secure communication coupling through an access control component of an *O / S (e.g., the STARKEY platform) that is programmed to identify the identity of a cellular service-enabled device (e.g., a mobile phone) that a user utilizes to dial and / or send text messages with random address signals corresponding to MOBILE ORIGINATING rather than MOBILE TERMINATING Codes. As detailed herein, at least some embodiments of the present disclosure, the access control component of the *O / S (e.g., the STARKEY platform) can be configured to hash a detected MSISDN (XMISDN), hash the detected MSISDN, and hash the resulting hash, such as, but not limited to, the last N digits of the MSISDN, which can provide a human-readable / recognizable hash value without compromising security (e.g., XM4, XYM4). As detailed herein, at least some embodiments of the present disclosure may enable an access control component of an *O / S (e.g., the STARKEY platform) to clear (e.g., not store, not persist) a detected MSISDN after computing the MSISDN hash.

[0239] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to connect an online environment with an element of a cellular network (e.g., an IN) by leveraging one or more elements of a cellular network (e.g., a control element of the IN (e.g., SCP / SCF), a billing element of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures in order to allow for a simplified and secure access operation sequence (including micro-billing) that can be initiated, executed, and completed based on a single step (e.g., a single button press) by the user / consumer without requiring any additional steps or any manual data entry by the user / consumer, such as by establishing a single active channel (e.g., a single transaction channel (STAR ​​BAND)) to connect an online environment with an element of a cellular network (e.g., an IN). Figure 13B are shown without limitation.

[0240] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to leverage existing digital cellular wallets (e.g., prepaid cellular accounts, prepaid SIM cards, non-prepaid cellular accounts with credit limits, etc.) and currencies in the hands of billions of people, accessible via telephone address signals (e.g., phone numbers), by utilizing one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures. While such digital wallets linked to cellular phones and their associated currency, billing, and payment arrangements have been limited to controlling how much network time and / or data each user / consumer is allowed to consume, 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 / payment arrangements to support a single operational access channel connecting an Internet-based environment and / or a virtual-based environment and / or a physical environment with the cellular network's communication environment to seamlessly utilize the cellular network's linked currency / billing / payment arrangements to access and / or consume 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.

[0241] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to facilitate seamless online transactions using existing digital cellular wallets by leveraging one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures.

[0242] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that aim to enable unrestricted access to cellular signals by utilizing one or more elements of a cellular network (e.g., a control element of an IN (e.g., SCP / SCF), a charging element of an IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to novel communication protocols and network architectures, thereby enabling:

[0243] 1. Make payments via a phone call that lasts one (1) second or less, thereby reinventing and repurposing cellular networks;

[0244] 2. Leverage scalable cellular networks with relevant elements for instant / real-time micro-billing;

[0245] 3. Provide new ways to leverage existing cellular digital wallets, active on billions of cellular users;

[0246] 4. Influence the movement of cellular money around the ring, in the cloud, and over the internet, in milliseconds, at marginal signaling cost, for only the uniquely intended transaction; and

[0247] 5. Provide a seamless, smooth and satisfying user experience based on a single operation access channel.

[0248] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to enable the use of new communication protocols and network architectures by leveraging one or more elements of the cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures in order to perform the various processes disclosed herein without restriction, without any external billing to the operator / carrier of the cellular network, without requiring any additional financial instrument disclosure by the user, and without requiring the user to use and / or participate in the management of security elements, for example, in the form of encryption keys, transaction PINs, usernames, or passwords.

[0249] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to utilize one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to novel communication protocols and network architectures in order to utilize prepaid billing, which can be in the form of unlimited airtime vouchers of varying denominations that users / consumers can obtain at retail stores or online and then load into their cellular wallets (accounts). For example, users can also send directly from one wallet to another using the provided cellular network services. For example, as users / consumers consume time and / or resources of the cellular network, the balance of the prepaid account associated with the corresponding cellular device can be depleted. In some embodiments, when the prepaid balance reaches zero, the cellular network service can be suspended until the user / customer replenishes their account.

[0250] Typically, postpaid subscribers are customers in good standing 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 consumption (POST) of cellular network resources and / or services. Prepaid billing typically involves substantially real-time communication, while postpaid billing is typically based on a periodic basis. As detailed herein, at least in some embodiments, one or more technical solutions of the present disclosure are designed to utilize prepaid, postpaid, hybrid, and mixed cellular billing models.

[0251] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to enable cellular communication by leveraging one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures so as to utilize, but not restrict, marginal network signaling during call origination setup, resulting in a cost of establishing a single operating access channel in a cellular network environment that may be tiny and fixed, allowing conversion of very low denominations / minor units (e.g., pennies), such that the technical solutions of the present disclosure can be simple (e.g., one 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).

[0252] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to enable digital content billing models that are more refined pay-per-view (PPV), single service unit (SSU), by leveraging one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to novel communication protocols and network architectures to unrestrictedly enable digital content billing models that are more refined pay-per-view (PPV), single service unit (SSU), where users / consumers pay only for discrete access and / or consumption of at least one product (e.g., digital content, physical product) or service (e.g., digital service, brick-and-mortar institution service). For example, paying for a single article, photo, song, video, or other creative art work and digital service that they want in the moment, rather than having to pay a recurring subscription fee.

[0253] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to enable any mobile network operator (MNO) of a cellular network to (for example, but not limited to) shift its legacy and analog telephone networks to a transaction platform, utilizing a single access channel for online and / or physical environments, utilizing edge network signaling, by utilizing one or more elements of a cellular network (e.g., control elements of the IN (e.g., SCP / SCF), billing elements of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to a novel communication protocol and network architecture.

[0254] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are designed to reduce the call hold time (CHT) to only one second and increase the busy hour call attempt (BHCA), the call density that the network can sustain during peak hours, 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 of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to a novel communication protocol and network architecture, based at least in part on the various HOOK FLASH signaling protocols described herein.

[0255] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address the problem of what is generally considered a lack of technically successful micro access control platforms 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 of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to new communication protocols and network architectures in order to utilize (e.g., reprogram) existing legacy cellular networks, by utilizing modern digital mobile phones and their subscriber identity modules (SIMs) that uniquely identify them, but are not limited to wireless "credit / debit cards."

[0256] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions designed to enable payment 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 of the IN (e.g., OCS)) that can be specifically programmed to convert and / or operate cellular signals according to a novel communication protocol and network architecture to allow a user / consumer to digitally sign a transaction by dialing the transaction amount from their mobile phone with a symbol character (e.g., a "*" key) to authorize payment.

[0257] Furthermore, because at least some embodiments of the present disclosure operate over a single access-controlled channel that logically links and synchronizes the cellular signaling channel with the Internet data channel (i.e., inline within a browser program or app where the items to be purchased are presented and consumed), transactions can be described as occurring out-of-band or out-of-band, and more relevantly, in preferred signaling embodiments, in STAR BAND.

[0258] Descriptive terminology used in at least some embodiments described herein:

[0259] Table 3 provides a complete description of abbreviations that may appear in this disclosure.

[0260] Table 3.

[0261]

[0262]

[0263]

[0264]

[0265]

[0266]

[0267] In at least some embodiments described herein, the terms "mobile," "cellular," "cellular," and "telephone" may be used interchangeably to describe modern GSM / TDMA / CDMA / UMTS / IP digital wireless telephones and communications networks. Although illustrations may depict smartphones, any phone may be suitable, including but not limited to basic feature phones, IP phones, and VOIP phones. Statements such as "mobile device" may be interchangeable with "user of a mobile device." In at least some embodiments described herein, although network elements may be referenced in the singular, they may include elements in the plural. In at least some embodiments described herein, a network subsystem (e.g., a billing system) may incorporate elements from other subsystems (e.g., an IN control system).

[0268] In at least some embodiments described herein, the terms "communication signal," "communication signal," "mobile communication signal," "mobile communication signal," "cellular communication signal," "cellular communication signal," "cellular communication signal," "cellular signal," and the like are used interchangeably and describe, but are not limited to, digital signals, data, and / or digital data packets that may be partially or fully encoded (e.g., but not limited to, bit / byte / hexadecimal / binary coded decimal format, etc.) for (1) cellular transmission using radio wave frequencies and associated elements / devices that are programmed to operate in accordance with one or more suitable cellular transmission protocols, (2) for transmission in accordance with one or more wireless Internet-related protocols and correspondingly programmed devices / elements, or (3) any combination of any embodiment of (1) and any embodiment of (2).

[0269] In at least some embodiments described herein, the term "element" or the like may describe a programmed computing device that executes at least a portion of a software program that resides partially or entirely in one or more non-transitory computer memory blocks (e.g., but not limited to flash memory, RAM, ROM, etc.), software programs, or a combination thereof.

[0270] In at least some embodiments described herein, the terms "cellular network," "mobile network," "cellular telephone network," "cellular mobile network," "cellular communication network," etc., may be used interchangeably.

[0271] In at least some embodiments described herein, terms such as "micro," "micropayment," "microtransaction," "microaction," "microactivity," and the like may describe one or more secondary units (e.g., one or more cents, etc.) of one or more currencies as defined, for example but not limited to, the ISO 4217 standard published by the International Organization for Standardization.

[0272] In at least some embodiments described herein, for example, micropayments describe small transactions in small units of one or more currencies as defined by the ISO 4217 standard (e.g., typically less than one dollar), while one or more of the principles / protocols / methods / systems / devices / platforms described herein can be programmed / used for activities / actions / transactions exceeding that amount. For example, transactions of $10 and above also apply. In some embodiments, one or more of the principles / protocols / methods / systems / devices / platforms described herein can be programmed / used for activities / actions / transactions that are typically settled using other banking instruments (e.g., debit and / or credit cards).

[0273] In at least some embodiments, the character "Y" in combination with other Y characters represents a telephone decimal digit (0-9), or collectively, an entire telephone number. Unless otherwise noted, the sequence +Y YYY YYYY may represent a typical e164 format MSISDN (e.g., 11 digits with + as the outbound international dialing symbol). The MSISDN may be transmitted and displayed as a calling line identifier (CLI).

[0274] In at least some embodiments, the character "X" herein may represent a decimal address signal (eg, the numbers 0-9). In some embodiments, the characters "X" and / or "Y" may represent randomly generated decimal numbers.

[0275] In at least some embodiments, the term "caller" may be interchangeable with party "A." Party may be interchangeable with an associated telephone device (phone). Embodiments may display callers as "A," "B," "C," etc., to distinguish between different callers.

[0276] In at least some embodiments, the characters "A" and "B" (etc.) represent cellular MSISDNs A and B, or cryptographically hashed cellular identities (XYM4-A, XYM4-B).

[0277] Enclosed square brackets "[]" represent wallets (e.g., Star Wallet).

[0278] Symbols “[A]” and “[B]” represent CELL wallets A and B (e.g., a prepaid account associated with a prepaid SIM card, a postpaid account with a cellular service operator, etc.).

[0279] In at least some embodiments, the notations "[*A]" and "[*B]" represent STAR Internet Wallets A and B. That is, wallets created and maintained by the systems and methods disclosed herein (e.g., wallets associated with a cellular identity and the illustrative STAR platform of the present disclosure).

[0280] In at least some embodiments, throughout the disclosed cellular identities, for example, MSISDN may be interchanged with cryptographically derived and / or enhanced identities, such as C24XYM according to the hashing methods disclosed herein.

[0281] In at least some embodiments, the NNN symbol may represent a microwave band data structure or a macro band data structure.

[0282] In at least some embodiments, the term MICRO herein may generally describe a data structure configured to represent payment units between $0.01 and $1.00. In at least some embodiments, the term MICRO herein may be extended to an upper limit of $9.99, such as, but not limited to, a fixed three-digit notation (NNN).

[0283] In at least some embodiments, the term MACRO herein may describe a data structure configured to have variable length and / or encoded units and a variable range of payments / amounts, typically exceeding micros, ranging from $1 to $1,000 or more in one embodiment.

[0284] In at least some embodiments, all star dialing numbers may include more digits than specified by the STAR P2P protocol (e.g., more than three digits in NNN embodiments) and may be parsed by elements of the cellular network, such as an access control mode (e.g., a cellular system billing and / or OCS (online charging system) configured to operate as described herein), to extract the first NNN signal (e.g., *NNNXXX, *NNN*XXX) of the MICRO band signaling digits from the star address to determine, for example, but not limited to, the cellular rate / toll / fee / charge to which the conversion transaction applies.

[0285] In some embodiments, the present disclosure may describe a prepaid cellular account whose monetary unit is legally backed network airtime, and an accounting test that may determine whether the account has sufficient credit balance to sustain the charges. It is understood that the various technical solutions of the present disclosure are also applicable to postpaid accounts, where the accounting test may determine whether the user has sufficient credit (i.e., credit worthiness) to sustain the debt resulting from the pending transaction.

[0286] Thus, while some embodiments may describe deducting the amount from a cellular account, it may equally be possible to debit (post) the amount to an account for later settlement. While technically, debiting and debiting may describe different bookkeeping principles, they apply here in the broader context of having sufficient credit in the account associated with the usage to sustain the charge, rather than in the narrower context of having a sufficient (prepaid) credit balance in the account. Therefore, the two terms may be used interchangeably.

[0287] Payment amount can be in USD, decimal or single While the examples herein may illustrate dollar ($) amounts, any currency (e.g., as defined by the ISO 4217 standard) may be similarly mapped to the disclosed dialed digits. In some embodiments, the dollar amount may be displayed as a flat price and then converted to local currency at the time of the transaction. In some embodiments, the dialed digits and corresponding currency are localized by referencing the MSISDN of the cellular device used to effectuate the payment. The digital store in the STAR Wallet is referred to herein as STAR CURRENCY, a highly fungible fiat-backed token.

[0288] In some embodiments, the term IP endpoint (IPE) herein describes a uniquely addressable and referenced Internet-connected component, including but not limited to discrete digital content or services, Document Object Model (DOM) elements in a browser page (for example, but not limited to, presented via XML or HTML), user interface elements on an Internet-connected device, applications, terminals, web pages, etc. In some embodiments, an IPE may be addressable by a unique Internet address, including but not limited to a socket address, port number, etc., coupled to a digitally identifiable element.

[0289] In some embodiments, the address signal for a cellular call may be prefixed with a symbol. This prefix may be, but is not limited to, an asterisk (*), a double asterisk (**), a hash (#), a double hash (##), a star-hash (*#), a hash-star (#*), or any other symbol or combination of symbols. In some embodiments, this symbol prefix shifts the address signal one position to the right, escaping the conventional dialing address field into a previously unused (e.g., asterisk) number field.

[0290] In some embodiments, but not limited to, a Mobile Switching Center (MSC) is referenced as the transaction node responsible for generating cellular micro-billing notes (records). Typically, the MSC is a switching element and function of traditional 2G / 3G circuit-switched telephone networks. In more modern 4G / 5G packet-switched telephone networks, such as those using the Internet Multimedia Subsystem (IMS) architecture and those using 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).

[0291] In some embodiments, regardless of whether a circuit, packet, or hybrid circuit and packet switching network architecture is used, an associated online charging system (OCS) typically manages user account balances and makes charging decisions. The OCS may include a session balance control function (SBCF), an account balance management function (ABMF), and a rating function (RF) to determine the tariff (i.e., charge) for communications.

[0292] For nearly 150 years, since the first telephone call, the ring has only transmitted a calling line identification (CLI). In some embodiments, the technical solutions of the present disclosure teach how to perform money transfers over a telephone ring. In some embodiments, "RING COMMERCE," "RING TRANSACTION(S)," and the like are terms coined herein to describe transactions conducted over the ring, thereby literally performing remote ring sales in an online and / or offline environment.

[0293] STAR ("*") is a universal key in a cellular matrix (a telephone dial pad). In some embodiments, elements of a cellular network can be programmed to recognize STAR ("*") as a symbolic network routing prefix and assign a name to a cellular network signaling and switching element (node) that provides services and controls for the micropayments disclosed herein in accordance with at least some of the novel communication protocols and architectures. In some embodiments, while the disclosed STAR node is described as a SIP signaling server, other signaling systems, protocols (e.g., but not limited to SS7 and ISUP) and / or entities can be used to achieve the same transaction results (e.g., microtransactions over a single access channel (interchangeably referred to herein as a STAR BAND)).

[0294] 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" may refer to a single physical processor with associated communication and data storage and database facilities, or it may refer to a networked or clustered complex of processors and associated network and storage devices, along with operating software and one or more database systems and application software that support the services provided by the server (e.g., a cloud server).

[0295] 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 communications network (e.g., the Internet); (2) providing the ability to run programs or applications on multiple connected computers (e.g., physical machines, virtual machines (VMs)) simultaneously; (3) network-based services that appear to be provided by real server hardware but are actually provided by virtual hardware (e.g., virtual servers) simulated by software running on one or more real machines (e.g., allowing movement and expansion / contraction without affecting service to end users). Of course, the above examples are illustrative and not limiting.

[0296] In some embodiments, according to the technical solutions of the present disclosure, a user (and / or an associated cellular device) simply dials an asterisk (*) followed by a number that matches the monetary amount, as described herein. In some embodiments, according to the technical solutions of the present disclosure, access to (event) activities (e.g., small payment transactions) can typically be completed in one second or less. In some embodiments, according to the technical solutions of the present disclosure, access to (event) activities (e.g., small payment transactions) can typically be completed in two seconds or less. In some embodiments, according to the technical solutions of the present disclosure, access to (event) activities (e.g., small payment transactions) can typically be completed in three seconds or less. In some embodiments, according to the technical solutions of the present disclosure, access to (event) activities (e.g., small payment transactions) can typically be completed in four seconds or less. In some embodiments, according to the technical solutions of the present disclosure, access to (event) activities (e.g., small payment transactions) can typically be completed in five seconds or less. In some embodiments, according to the technical solutions of the present disclosure, the user's cellular device generates an authenticated (signed) cellular signal (e.g., an address signal) that enumerates monetary amounts that can be processed in the following manner:

[0297] 1) Presentation of ringtones; secondly

[0298] 2) Call connection and disconnection (eg, HOOK FLASH / WINK protocol).

[0299] In some embodiments, the technical solutions of the present disclosure uniquely utilize signaling techniques, such as, but not limited to, the "hook flash" or "blink" disclosed herein, to instantly switch and conduct micro-transactions on a device (e.g., a smartphone) by instantaneously connecting and then disconnecting a call, by generating an event record (e.g., a billing receipt at the originating switching element (MSC or appropriate IMS billing node)) in an account associated with the corresponding cellular device and tracked in the database of the relevant cellular operator / carrier. In some embodiments, one or more technical solutions of the present disclosure may be referenced as "FLASHCOMMERCE." In some embodiments, according to the technical solutions of the present disclosure, the resulting event record (e.g., a cellular billing receipt, also referred to herein as a CDR (Call Data Record)) contains a star signaling event that can be used to debit (or deduct) the monetary value of the dialed digits from an account associated with the calling device (caller account). In some embodiments, according to the technical solutions of the present disclosure, an event record (e.g., a cellular billing receipt (billable CDR)) may be generated when a call lasts for one second. In some embodiments, according to the technical solutions of the present disclosure, an event record (e.g., a cellular billing receipt (billable CDR)) may be generated when a call lasts at least 500 milliseconds. In some embodiments, according to the technical solutions of the present disclosure, an event record (e.g., a cellular billing receipt (billable CDR)) may be generated when a call lasts at least 100 milliseconds. In some embodiments, according to the technical solutions of the present disclosure, an event record (e.g., a cellular billing receipt (billable CDR)) may be generated when a call lasts at least 50 milliseconds. In some embodiments, according to the technical solutions of the present disclosure, the resulting event record (e.g., a cellular billing receipt (billable CDR)) may be generated when a call lasts at least 1 millisecond.

[0300] [ Figure 1 ]

[0301] Figure 1 The present invention relates to a remote control access solution system and method according to one or more embodiments of the present disclosure. An exemplary computing device (Internet-connected device) 100 running an Internet application (IAPP) 101 requests an Internet resource (e.g., a web page) through an application programming interface (API) 102 connected to a remote server 111, which is hosted in a cloud 110 in one embodiment. The remote server 111 returns at least one application instruction (represented by a generic script notation "") to the IAPP 101, which renders and displays an access controller interface element 103 having an exemplary access code NNN displayed, and in one embodiment, a link URL 131 referencing an access-restricted digital resource (130) (e.g., Internet-hosted content) and / or an access-restricted service 132.

[0302] In one embodiment, the API can transmit a plurality of data, such as, but not limited to, an access code NNN, a URL 131 referencing Internet content or service 132, a parameter identifying a cellular device (e.g., MSISDN) for a previously identified cellular device, and any other access control metadata. The cellular identifier can be associated with the Internet-connected device 100, or other previously identified cellular devices. Upon receiving a request for an Internet resource, the remote server 111 responds to the IAPP 101 with at least one application instruction 102 (again, as depicted by the general scripting notation "") to present a door controller interface element 103.

[0303] At least one application instruction 102 may, but is not limited to, include code (e.g., HTML markup and / or CSS) for styling the access controller interface element 103 and the displayed access code (NNN). In addition to providing a script for styling the interface element 103, the at least one application instruction may include service logic (e.g., JavaScript) to be executed when the interface element is activated. In one embodiment, without limitation, the at least one application instruction may encode a button rendering script (e.g., using HTML, CSS, or any combination thereof) to stylize the interface element 103 and the displayed access code (NNN), and further provide service logic that communicatively couples the interface element 103 to the cellular network 120 control mode 121.

[0304] In one embodiment, at least one application instruction communicatively couples the access controller interface element 103 to the cellular network control module 121 and may further instruct activation and / or initiation of a mobile-originated cellular communication protocol to transmit / issue an access request, including an access code NNN in an address signal prefixed with a symbol (e.g., *NNN as disclosed herein) to detect 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 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 activation of the access controller interface element 103 when the user of the computing device 100 scrolls through online content and advances to a portion of the online content that will display the access controller interface element 103, which portion will display the access controller interface element 103 as being operatively linked to the access-restricted digital resource (e.g., the access controller interface element 103 is in focus on the screen of the computing device 100). The mobile-originated communication protocol may be, but is not limited to, a telephone 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 transmitted along the cellular signaling path 105 to the cellular network hosted access control scheme 121, which may then in turn convey at least one access procedure instruction, via the remote Internet access control server 111 (e.g., in one embodiment, addressed at a converted symbolic network routing prefix, as described below in FIG. 15 ), back to the access controller interface element 103 using the API 104.

[0305] In some embodiments, the client-server interaction as described between the Internet client device 100 (running the IAPP 101) and the remote Internet access control server 111 can occur along an established Internet communication path (e.g., the API pattern 104, represented by the general HTTP " / / " communication protocol). While this communication path can be used in the disclosed pattern (e.g., in the modified DCB embodiment newly disclosed herein), one technical solution in the disclosed remote programmatic access pattern is that, in one embodiment, the remote Internet access control server (111) can now inject new programming logic into the IAPP (101) executing on the client device (100) that redefines and perspectives the client-server communication from communication that is typically conducted over the Internet, such as, but not limited to, using HTTP GET / PUT or JSON data exchange protocols along the Internet communication path 104, to communication that is now transmitted over the cellular network 120, using the Mobile Origin (MO) signaling protocol along the cellular communication path 105. By communicating, therefore, over cellular rather than internet channels, data is securely transmitted outside the internet band, or above the band as described in detail herein (e.g., in the star band).

[0306] Thus, when the Internet-connected device 100 detects that the access control interface element 103 has been activated (e.g., a user clicks / clicks on the interface element), service logic programmed and provided by the remote Internet access control server 111 is executed. In one embodiment, the service logic can be configured to transmit access control data (e.g., " / / ," as indicated by "HTTPS: / / ") via the Internet communication channel 104, including, but not limited to, utilizing an Internet API to transmit an access code (NNN) and a cellular device identifier (e.g., MSISDN) to the remote Internet access control server 111. In one embodiment, the service logic can transmit access control data via the cellular communication channel 105, using mobile source signaling directed to the network access control module 121, which can then transmit access control instructions back to the remote Internet access control server 111, as described above.

[0307] In one embodiment, upon receiving the access control data via the Internet communication channel 104, the remote Internet access control server 111 may then request the cellular network managed access control module 121 to grant access based at least in part on executing the newly configured cellular service logic on the communicated data (e.g., access code NNN and cellular device identity, such as MSISDN). In one embodiment, the access control data may be transmitted to the cellular network access control element 121 via the cellular communication path 105 (as described above), bypassing the remote Internet access control server 111.

[0308] In one embodiment, the newly configured cellular network hosted access control module 121 recognizes and interprets the displayed access code NNN to enumerate the fee ($N.NN) that will be applied to the account associated with the identified cellular device (e.g., MSISDN) in order to grant access to the referenced content or service 132 (e.g., at URL 131). In one non-limiting embodiment, the door controller interface element 103 is presented by the IAPP 101 as a graphical user interface element (e.g., a transaction submit button) that displays the access code NNN, which in one embodiment is formatted as a purchase price (e.g., $N.NN or As disclosed herein), for accessing Internet content or services 132.

[0309] The graphical user interface element 103, defined by at least one application program instruction 102, received from the remote Internet access control server 111 as described above, may thus be presented as a payment button of uniform design (e.g., shape, size, and color), and appropriately labeled so as to be immediately recognizable as a cellular billing payment method, displaying the transaction amount ($N.NN or ), for accessing linked Internet content or services (132). Presenting a consistently branded and stylized, and therefore instantly recognizable, payment instrument (e.g., interface element) is critical to generating trust in and capturing the mass market for cellular billing, as disclosed herein.

[0310] Thus, in one embodiment, the cellular network control mode is a cellular billing and charging mode (e.g., OCS), which is configured as described herein with reference to the following Figure 15A and 15B to determine whether the account associated with the identified cellular device (e.g., MSISDN) has sufficient credit to maintain $N.NN enumerated by access code NNN.

[0311] Upon determining that the cellular account associated with the provided cellular identity (e.g., MSISDN) has sufficient credit to sustain the $N.NN charge enumerated by the access code NNN, the cellular network hosted access control mode 121 may communicate the successful transaction to the remote server 111, which in turn may 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 connected Internet device 100 to access (retrieve) and present the linked content or service 132.

[0312] In at least some embodiments, the access-restricted digital resource (130) may be an IAPP 101 (valid authentication identity (eg, MSISDN)) with no competing registrations.

[0313] [ Figure 2 ]

[0314] Figure 2 Describes the method for implementing Figure 20 Another schematic diagram of a payment network architecture for at least a portion of a mobile communication signal. Figure 2 Schematic diagram of the life cycle of digital content including payment and access through a payment network architecture.

[0315] In some embodiments, the access control platform 210 hosts access-restricted digital services and / or content under a virtual lock 211. In some embodiments, an internet service can request an access control button 213 via an appropriate communication, messaging, and / or interface protocol. For example, in some embodiments, the internet service can utilize, for example, an application programming interface (API) to send a request to the access control platform 210, which can respond by returning an interface element via the same or a different API. The interface element can include a door access button 213 and / or any other suitable interface element.

[0316] In some embodiments, the term "application programming interface" or "API" refers to a computing interface that defines interactions between multiple software intermediaries. The API defines the types of calls or requests that can be made, how the calls should be made, the data formats that should be used, the conventions to be followed, and other requirements and constraints. An API can be completely custom and component-specific, or it can be designed based on industry standards to ensure interoperability, enabling modular programming through information hiding, which allows users to use the interface independently of the implementation.

[0317] In some embodiments, a user can navigate to content from an Internet service using an Internet device 212. In some embodiments, the Internet device 212 can 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, Really Simple Syndication (RSS) feeds, or any other suitable Internet-accessible content access and / or delivery software or any combination thereof.

[0318] In some embodiments, upon navigating to content, the internet service may provide a content access interface to the internet device 212, presenting the content and an interface element including 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 representing 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 optional for the content. For example, the access control button 213 may be rendered as, for example, an overlay of the content interface element, adjacent to the content interface element, on a list row next to the content interface element, with a lead pointing to the content interface element, or by any other design feature or any suitable combination thereof.

[0319] In some embodiments, a user can generate an access request to access content by selecting an access control button 213, a content interface element, or both via internet device 212. In some embodiments, the access request can include a communication of a temporary transaction event in the access control ledger. In some embodiments, the transaction event can be for a value associated with access to content and an intended phone device 221. In some embodiments, the intended phone device 221 can include a suitable phone device 221 that has been registered in the access control ledger for the specific content and / or specific internet service associated with the value of the transaction event. In some embodiments, the phone device 221 can be registered by, for example, pairing, designating, linking, or otherwise associating a unique identifier associated with the phone device 221 with the transaction event. In some embodiments, the unique identifier can include, but is not limited to, an MSISDN, a cryptographically hashed MSISDN, or an enhanced hashed MSISDN of the phone device 221.

[0320] In some embodiments, the access control button 213 may indicate a request for the user to pay an access fee by activating (e.g., touching or otherwise selecting via a suitable input device) the access control button 213 to view the content on the Internet device 212. Thus, the access control button 213 may display the value (price) of accessing the content. Figure 2 In the example shown, the user is therefore asked to pay to access the service or content, as indicated by the price presented on the access control button 213.

[0321] In some embodiments, to fulfill a request to pay for access to content, a user may initiate a transaction using a telephone call from a telephone device 221, enumerating the requested price using an address signal comprising a symbol prefix followed by digits. A specially configured IN 220 may utilize the address signal to route the telephone call and execute the transaction based on the symbol prefix followed by digits. Figure 2 In the example depicted in FIG, a user may dial *10 from a telephone device 221 , presented in portrait mode, utilizing IN 220 , in greater detail.

[0322] In some embodiments, the internet device 212 and the phone device 221 are the same device. Thus, upon activating the access control button 213 by clicking the button, the mobile device 212 / 221 can be controlled to open a native phone dialer followed by the number enumerating the price in a currency appropriate for the phone number. For example, the access control button 213 can include software instructions to instruct the mobile device 212 / 221 to open a native phone dialer pre-marked with the price of the content, e.g., *10 for 10 cents.

[0323] In some embodiments, internet device 212 and phone device 221 are separate devices. Thus, a user can read the price and manually enter a symbolic prefix followed by a number enumerating the price into a dialer. In some embodiments, communication between internet device 212 and phone device 221 can enable internet device 212 to automatically control phone device 221 to open a local phone dialer pre-labeled with the symbolic prefix followed by a number enumerating the price in a currency appropriate for the phone number. For example, access control button 213 can include software instructions to instruct internet device 212 to broadcast a wireless signal to phone device 221. The wireless signal can include an instruction to phone device 221 to open a local phone dialer pre-labeled with the price. In some embodiments, wireless signal transmission / communication can 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.

[0324] In some embodiments, NFC may refer to a short-range wireless communication technology in which NFC-enabled devices are "swiped," "bumped," "tapped," or otherwise moved in close proximity to communicate. In some embodiments, NFC may include a group of short-range wireless technologies, typically requiring a distance of 10 cm or less. In some embodiments, NFC may operate over the ISO / IEC 18000-3 air interface at a frequency of 13.56 MHz, with rates ranging from 106 kbit / s to 424 kbit / s. In some embodiments, NFC may involve an initiator and a target; the initiator actively generates a radio frequency field that can power a passive target. In some embodiments, this can enable NFC targets to take very simple form factors, such as tags, stickers, key fobs, or cards that do not require batteries. In some embodiments, NFC peer-to-peer communication can occur when multiple NFC-enabled devices (e.g., smartphones) are brought into close proximity with each other.

[0325] Thus, in some embodiments, the internet device 212 can be configured as a point-of-sale device for making face-to-face small payments for physical items and / or services, such as at a physical vending machine. The internet device 212 can be used to generate a price for the physical item and an identifier (e.g., SKU, SKURL), and then the internet device 212 and the phone device 221 can register and / or pair the price of the physical item. Thus, when using a wireless signal (e.g., RFID, NFC, Bluetooth, etc.), the wireless signal can instruct the phone device 221 to open a local phone dialer pre-tagged with the price of the physical item and / or service.

[0326] In some embodiments, upon pressing the connect button 222 on the access control element (e.g., a green phone), a call with an address signal enumerating the price of accessing the content is transmitted 223 over the radio access network (RAN). IN 220 performs an AAA (Authentication, Authorization, and Accounting) procedure, wherein the accountant determines whether the account associated with it has sufficient credit (US$0.10 according to the above example) to complete the call. Upon successful credit verification, the call and the associated address signal (*10), including the MSISDN transmitted as the caller identity, are routed to the access control element 224.

[0327] In some embodiments, upon receiving an address signal, the access control platform (e.g., the STARKEY platform) queries the access control ledger to determine whether a transaction from the MSISDN for the amount signaled by the signal (e.g., 10c signaled by *10) is expected. In some embodiments, upon determining that the transaction is expected, the access control platform may connect to the call and then disconnect, e.g., by performing the disclosed wink signaling to effect and complete the transaction, instructing the network to answer the call OFFHOOK, thereby starting to time the call at the signal tariff rate (in this example, 10 cents).

[0328] In some embodiments, the access control platform instructs the network to replace the call ONHOOK, e.g., after a short wink, thereby completing the transaction. Replacing the call ONHOOK causes the IN to generate a billing CDR for the transaction amount (10c) and debit and / or deduct the transaction amount from the account associated with the calling party.

[0329] In some embodiments, the access control platform waits for signaling to confirm that the call has been disconnected from the network. If the network indicates that the user has disconnected the call before the call goes offhook (e.g., presses the red phone icon) (e.g., sends a SIP CANCEL message to the access control platform), the IN 220 may cause the transaction to abort and not complete.

[0330] In some embodiments, upon determining that the transaction is expected, the access control platform (e.g., the STARKEY platform) may register / receive and extract the address signal as described herein without going offhook. For example, where the address signaling in the present disclosure may have no associated charge (e.g., no CDR), the MNO element may thus route the call or SMS to the access control platform (e.g., the STARKEY platform) without any further processing. In at least some embodiments, the novel SIP communication protocol of the present disclosure may use one of the following: 1)

[0332] >SIP INVITE

[0333] <100

[0334] <SIP BYE 2)

[0336] >SIP INVITE

[0337] <100

[0338] <SIP CANCEL.

[0339] In some embodiments, upon receiving a signal confirming that the hook flash event was successfully completed, i.e., the CDR was successfully recorded and the amount was deducted from the caller's account, the access control platform can update the access control ledger, marking the transaction from expected "set" to "satisfied" and / or "successful", and transmit it to the access control button 213. In some embodiments, upon receiving a micropayment confirmation indicating that the transaction was "satisfied" and / or "successful", the Internet service can control the service or content 225 to be unlocked for access via the mobile device 212 / 221, for example, by, but not limited to, downloading the Internet service (access restricted) via the data network connection 226 for display on the display 230 of the mobile device 212 / 221.

[0340] Thus, to effectuate payment for digital content and / or services, a user may dial the price indicated by access control button 213 and use a telephone call (e.g., one second or less) to unlock the content for consumption.

[0341] [ Figure 3 ]

[0342] Figure 3 A payment network architecture according to one or more embodiments of the present disclosure is described in further detail. Figure 3 A massively parallel cellular transaction system and related functional entity relationships utilizing a symbolic prefix and address signaling protocol and an access control platform 310 is graphically illustrated.

[0343] In some embodiments, the access control platform 310 hosts digital content that requires a small payment to access. The access control button 311 displays the requested payment amount (e.g., $N.NN or In some embodiments, IN 320 is used to send signals and make small payments.

[0344] In some embodiments, the previous steps may be performed to register and pair the user's cellular identity with the access control platform 310. In some embodiments, the cellular identity may include, for example, the user's MSISDN-Y. Registration of the cellular identity may be performed, for example, through a challenge and response method, user input, or other suitable registration techniques to pair the cellular identity with a specific intended transaction. This pairing combines the amount presented by the access control platform 310 in the access control button 311 viewed in a browser or app with the registered cellular identity, uniquely binding and stashing the pending transaction with the user.

[0345] In some embodiments, because the requested payment ($N.NN) is uniquely tied (logically coupled) to the user's registered cellular identity (MSISDN-Y), the systems and methods disclosed herein record such pending transaction as expected, for example, in an access control ledger 370 (e.g., a record in a centralized database, or a contract in a decentralized blockchain) that lists the source of the expected NNN series address signal in the MSISDN.

[0346] In one or more embodiments where the access control ledger 370 includes a blockchain, the pending transaction represented by the contract is then fulfilled (satisfied) upon receipt of a cellular signal matching the recorded expectations, thereby authorizing the transfer of funds to the content creator or publisher (@P).

[0347] In some embodiments, the exemplary computer-based inventive system / platform, the exemplary computer-based inventive device, and / or the exemplary computer-based inventive components of the present disclosure may be configured to interact with and / or store data in one or more private and / or privately permissioned cryptographically protected distributed databases, such as, but not limited to, blockchain (distributed ledger technology), Ethereum (Ethereum Foundation, Zug, Switzerland), and / or other similar distributed data management technologies. For example, as used herein, a distributed database, such as a distributed ledger, ensures data integrity by generating a chain of data blocks linked together by cryptographic hashes of data records in the data blocks. For example, a cryptographic hash of at least a portion of a data record in a first block, in some cases combined with a portion of a data record in a previous block, is used to generate a block address for a new digital identity block that follows the first block. As an update to a data record stored in one or more data blocks is generated, a new data block is generated containing the corresponding updated data record and linked to the previous block, with an address based on the cryptographic hash of at least a portion of the data record in the previous block. In other words, the linked blocks form a blockchain, which itself contains a traceable sequence of addresses that can be used to track updates to the data records contained therein. The linked blocks (or blockchain) can be distributed across multiple network elements within a computer network, such that each element can maintain a copy of the blockchain. A malicious network element attempting to compromise the integrity of the database would have to recreate and redistribute the blockchain faster than honest network elements, which is computationally infeasible in most cases. In other words, data integrity is ensured by multiple network elements in the network having copies of the same blockchain. In some embodiments used herein, a central trusted authority for sensor data management may not be required to ensure the integrity of a distributed database hosted by multiple elements in the network.

[0348] In some embodiments, the exemplary distributed blockchain-based ledger implementations and related devices of the present disclosure 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, the exemplary smart contracts can be configured to be partially or fully automated and / or self-executing. In some embodiments, the exemplary inventive asset tokenization distributed blockchain-based ledger implementations of the present disclosure can utilize a smart contract architecture that can be implemented through a replicated asset registry and execute contracts using cryptographic hash chains and Byzantine fault-tolerant replication. For example, each element in a peer-to-peer network or blockchain distributed network can act as a property registry and escrow, thereby executing ownership changes and enforcing a predetermined set of rules governing transactions on the network. For example, each element can also check the work of other elements and, in some cases, act as a validator, as described above.

[0349] In some embodiments, an inverse correlation between an activated access control button 311 for online purchase of a uniquely identifiable digital product (e.g., by SKU or other identifier of content and / or services) and an expectation of waiting for a matching cellular signal from a known MSISDN enables the user to dial the listed price ($N.NN) without having to enter any additional beneficiary addressing information to which the resulting micropayment will be directed.

[0350] In some embodiments, this transaction simplicity and unified addressing protocol, which binds signal prices and providers of content and / or services, is achieved through an inverse association between payee and payer and the resulting expectations set for the selected content and / or service. Thus, the mapping between the cellular micropayment signal, the purchased digital content, and the provider is seamlessly stitched together in the backend, such as the public access control ledger 370, and is therefore completely transparent to the consumer (caller).

[0351] For example, a digital product or service SKU from provider @P requires a A small payment of ($N.NN) and activation of the access control button 311 at date timestamp DT may result in the following expectation and associated metadata, as described in the access control ledger 370, where " / " represents the record field separator:

[0352] [Y:NNN / @P / SKU / DT].

[0353] Thus, in some embodiments, when the address signal *NNN is received from MSISDN-Y, and the cellular wallet (e.g., 333) associated with MSISDN-Y has sufficient credit balance to maintain The provider P is credited with the SKU sold and a new transaction date timestamp (DT) is recorded. By recording the initial timestamp of at least one activity associated with the button (e.g., activation of the button (e.g., clicked / selected)), the access control platform can disengage upon timeout, during a time interval in which no such cellular signal is received, to free up any unused communication resources.

[0354] In some embodiments, a specific series of address signals may be expected from a known MSISDN, based on expectations set in the access control ledger 370. Thus, in some embodiments, the access control platform 310 may use transaction pre-identification to ensure that only the correct address signals, and therefore the correct payment amounts, are accepted for processing. Thus, if a user mistakenly dials, say, *001 (1 cent U.S.) when the pending transaction expects *010 (10c), the access control platform 310 may benevolently reject the transaction because there is no matching expectation. Thus, the access control platform 310 may avoid using the disclosed hook-flash signaling protocol, which could erroneously execute any transaction and debit an incorrect amount from a cellular account.

[0355] In some embodiments, cellular signaling mapped to address signals of internet endpoints and products allows for highly parallel transaction processing where many users (thousands or even millions) can simultaneously or substantially simultaneously view the same digital content, request the same micropayment, and all users can then simultaneously or substantially simultaneously send the same signal to conduct the same micropayment transaction, all without interfering with the signal of a unique transaction that might inadvertently authorize access and delivery by one consumer to another.

[0356] Thus, in some embodiments, by setting the transaction expectation [Y:NNN], only a phone device with MSISDN-Y that is sending the address signal NNN and has a sufficient balance in the associated cellular wallet [Y] to maintain the charge of $N.NN fees according to the disclosed method and system can unlock the content (SKU) associated with the activated $N.NN access control button 311. This highly orchestrated and staged one-to-one, many-to-one, and many-to-many user-content relationship building enables more efficient and secure large-scale small-value payments.

[0357] Figure 3 The access control platform expectations and resulting transactions from three users are shown, each recorded in the access control ledger 370 before the user signals the relevant address. These expectations (312) are set in the access control ledger 370, which can further record transaction metadata, including but not limited to:

[0358] 1. The unique identity of the digital publisher (@P) presenting the access control button 311, which in some embodiments is the MSISDN itself. Thus, the unique identity of the digital publisher (@P) describes the provider access control wallet 380 [*P], which can be registered as a key for the content publisher, using similar registration and / or pairing techniques as described above for user phone devices, for example, using the access control platform API.

[0359] 2. Identify the SKU (stock keeping unit) of the digital content or service purchased, and

[0360] 3. Timestamp of button activation (eg, years to milliseconds format YYYYMMDDHHMMSSMMM or any other suitable timestamp format).

[0361] 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., who are viewing the same or different access control buttons 311, managing access to the same or different digital content, requesting the same or different payment amounts, can securely signal substantially simultaneously, in parallel.

[0362] In some embodiments, on each A, B, C telephone device that transmits its respective NNN series address signal, the IN 320 performs an AAA (authentication, authorization, and accounting) step, wherein the latter step determines whether each cellular account [A], [B], [C] associated with the caller (A), (B), (C) has sufficient credit ($N.NN), based on a direct mapping of the address signals to monetary values, in order to complete the call setup and pending micro-transaction.

[0363] In some embodiments, if the account can afford the associated fees, such as Unit A 99 cents for unit B and 10 cents for unit C, the call passes billing verification and is routed to the access control platform 310 (e.g., based on the symbol prefix and / or equivalent internal routing short code). In some embodiments, the access control platform 310 can then query the access control ledger 370 as a pre-transaction verification step to determine whether the incoming signal from the corresponding telephone device is expected.

[0364] In some embodiments, the pre-transaction verification step uniquely ensures that the cellular user does not inadvertently mis-dial the payment amount, as the transaction is only executed if the active payment expectation (312) matches the address signal (322) received from the intended cellular MSISDN-Y.

[0365] In some embodiments, upon satisfying the wishes of each cellular user, the access control platform 310 executes a hook-flash protocol, causing the IN 320 to generate a CDR and complete the corresponding transaction. In particular, the CDR may be generated upon receiving confirmation that the call of the relevant cellular user has been disconnected by the access control platform 310 rather than by the cellular user.

[0366] In some embodiments, a conditional network disconnection where a CDR is created where the access control platform 310 is disconnected is achieved by momentarily pressing the phone disconnect button after pressing the phone connect button, preventing the user from placing a call interruption setting ABORT for such a duration that sufficient time is allowed for the address signal to reach the access control platform 310, while also preventing the transaction from being disrupted by the generation of a CDR. In some embodiments, since the CDR is used to debit and / or deduct the price from an account associated with the cellular user, the invalid generation of the CDR causes the transaction to be aborted. In some embodiments, upon receiving a successful transaction completion indication (e.g., a positive access permission indication), the access control platform 310 may 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 amount due.

[0367] The access control platform 310 then communicates with the Internet endpoint (IPE) and the provider (@P) to confirm that the transaction for the relevant SKU item has been completed, allowing the digital content to be unlocked, thereby granting content access rights to the user through the IAPP. In some embodiments, the provider receives a UUID that uniquely identifies the transaction.

[0368] This expected and proven signaling protocol ensures that the payment amount transmitted in the cellular address signal is debited from the cellular user's account before access to the digital content is granted. Thus, in the illustrated example, the three micropayment transactions shown arrive essentially simultaneously from three phone devices, resulting in the following three chronologically ordered cellular accounts ([wallets]) being debited:

[0369] [B] -$0.02 (344)

[0370] [US]-$0.99(333)

[0371] [C] -$0.10(355).

[0372] And accumulate to generate the access control system register (wallet) credit limit:

[0373] [*]=[*]+1.11USD(360).

[0374] Thus, the access control platform 310 acts as a micro-clearing house for content publishers. The cumulative access control platform register (360) is determined by the sum of all CDRs associated with the access control platform within a defined transaction billing period (e.g., daily, weekly, monthly), as shown in the following series:

[0375] [A,*NNN]+[B,*NNN]+[C,*NNN]....

[0376] In some embodiments, IN 320 may charge a micropayment conversion fee (%X) as a percentage of the transaction. Similarly, access control platform 310 may charge a transaction processing fee (%Y). The content publisher may then accumulate a cumulative balance in their associated access control platform wallet 380 [*P] for each $N.NN transaction, as shown below:

[0377] [*P]=[*P]+((100-XY) / 100x$N.NN).

[0378] In some embodiments, a 10% IN 320 fee and a 5% access control platform 310 fee may result in a majority (85%) of microtransactions rewarding content publishers. Thus, the payment may comprise a real and sustainable revenue distribution.

[0379] Upon deducting any percentage of interchange (%X) and transaction (%Y) fees, the access control platform 310 may allocate the accrued net payment revenue for each transaction by debiting their respective access control platform wallets 380:

[0380] [*PA]=[*PA]+(100-XY) / 100x 0.99

[0381] [*PB]=[*PB]+(100-XY) / 100x 0.02

[0382] [*PC]=[*PC]+(100-XY) / 100x 0.10.

[0383] In some embodiments, these funds may be marked as “pending” until IN 320 ultimately pays access control platform 310 .

[0384] In some embodiments, an Internet application (IAPP) on the user's phone device can request a micropayment transaction using the API, which presents an access control button 311 user interface element displaying the 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.

[0385] This 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 real-time transaction payment channel between the phone device, IN 320, and the Internet application in a single, independent user interface element.

[0386] In some embodiments, a two-way communication channel, along with micropayment expectations, which as disclosed, uniquely identifies and binds a symbolic prefix address signal from a known cellular device identity that is matched to digital content or services at a signal price, carries signaling in substantially real time between cellular phones, cellular switches, internet-based access control elements, and access control buttons, including, for example, internet buttons, in accordance with the disclosed methods and systems.

[0387] [ Figure 4A ]

[0388] Figure 4A A logical representation of switching circuit IN 460 (e.g., a telephone network) and device A 450 is depicted. In some embodiments, this architectural abstraction depicts core elements in access control platform transactions; some elements may be omitted for clarity. Some embodiments may have a different allocation of physical elements than shown; however, the physical separation of the logic shown does not affect the disclosed modeling.

[0389] In some embodiments, internet-connected device B 410 420 displays a screen requesting access to digital content or services from a user of the access control platform. Device B 420 may comprise an internet-enabled mobile phone whose internet browser links to a web page or application presenting internet content or services. Alternatively, device B 420 may be a personal computer with a browser or software connected to the internet. Thus, device B 420 and cell phone A 450 may be the same physical device.

[0390] In some embodiments, when rendering a screen for an access control platform transaction, device B 420 connects to the access control element 440 via a published API and requests an access control button (430). In some embodiments, the API allows the IAPP to specify a transaction amount for the access control platform (e.g., the amount disclosed herein). and *NNN address signal) and the SKU purchased. Each element presented on the screen requesting access to a control platform function can be further identified by a unique digital ID linked to the transaction.

[0391] In some embodiments, when device A (450) has previously conducted an access control platform transaction using IAPP and has been registered and / or paired for a pending transaction, as described above, an expectation may be set on the access control element (440). In some embodiments, the expectation may include a signal from a device signaling an *NNN address identified by MSISDN-A. For example, such an expectation may be annotated herein as [A:NNN], but any other suitable annotation may be used. In some embodiments, the access control platform API establishes two-way communication between the access control element (440) and the STAR button (430), allowing transaction events to be communicated between them. One such two-way communication protocol utilizes IP sockets.

[0392] In some embodiments, upon clicking the access control button (430), the transaction and associated channels are activated, prompting the user to dial the *NNN address. While the access control button (430) may be automatically activated, since multiple buttons may be displayed on a single screen, each associated with different content / services, clicking or drawing focus to activate the access control button (430) may be a mechanism for selecting the desired item to purchase.

[0393] In some embodiments, user A can dial *NNN on device A (450) to make a payment in US dollar notation ($N.NN). In another embodiment, user A can dial *NN or *0NN (with leading zero) to make a payment in cents. The transaction signal may be transmitted via IN 460 (eg, a radio access network (RAN)), such as, but not limited to, TDMA / CDMA signaling or Session Initiation Protocol (SIP).

[0394] In some embodiments, a symbol prefix in a cellular address signal, such as an asterisk, a hash sign, an ampersand, etc., is accessed upon touching a symbol key (470). For example, an asterisk may be used for the symbol 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 symbol prefix may route a call to an access control element (440) along a star-shaped relay or universal resource indicator (URI).

[0395] In some embodiments, when *NNN is dialed, the mobile originating switching element (e.g., MSC 480) enters the Originating Basic Call State Model (OBCSM) and encounters the Initial Detection Point (INITDP: DP2 Collected_Info). INITDP establishes a call control dialog in which the Service Control Point (SCP / gsmSCF) is not displayed. In some embodiments, the MSC / SCP dialog is established using the MAP / SS7 signaling protocol.

[0396] In some embodiments, the SCP performs a credit verification on device A 450 by querying the cellular wallet (490), an account associated with device A, to determine whether user A has sufficient credit to complete the call. That is, in this example, it determines whether user A has at least $N.NN credit in the associated cellular account (490) according to the disclosed mapping. In some embodiments, the cellular wallet 490 is managed by the IN billing system or online charging system (OCS).

[0397] In some embodiments, upon determining that user A has sufficient credit, the SCP instructs the MSC (480) to proceed with the call, and the MSC 480 then routes the call request to the access control element (440). In one switching embodiment, the MSC routes the call along an associated symbol (e.g., star) relay to the GMSC / SBC, which in turn converts the ISUP to SIP signaling.

[0398] In some embodiments, although Figure 4A The MSC 480 is depicted as being connected to the access control element (440) via a linear path and a single hop on the cellular wallet (490), but this merely illustrates the logical entity relationships within the depicted channel. That is, the cellular wallet (490) may not actually be connected to the access control element (440) at all, nor participate in the call signaling path or any protocol conversion. For clarity, the actual network routing, protocols, and related links accessed by the cellular wallet 490 are not shown.

[0399] In some embodiments, upon receiving a call request from the access control element (440), a determination is made as to whether the call is being placed from MSISDN-A, sending address signal NNN (i.e., record [A:NNN] exists), set upon user-activated access control button 430. If such a desire is met, the access control element (440) may instruct the MSC (480) to provide a ring back tone (RBT) to device A (450), and then, in accordance with the hook flash signaling protocol disclosed herein, temporarily instruct the MSC 480 to place the call off / on hook, and then thereafter temporarily replace the call back on / hook to perform the transaction.

[0400] Therefore, in some embodiments, the user experience of the access control platform:

[0401] 1. Instant ringback tone, followed by

[0402] 2. Instant call connection and disconnection.

[0403] In some embodiments, the telephone device (450) may then display a symbol prefix call with a duration of 00:01 seconds. Thus, in some embodiments, the flashlight protocol presents an auditory (ringback tone) and visual (instant connection) confirmation that the call is up, connected, and then completes the drop. The hook flash signaling disclosed herein generates a $N.NN call data record (CDR) billing ticket at the MSC (480) for the star dialed digits NNN. In a prepaid cellular embodiment, this amount is debited to the cellular wallet (490) in substantially real time.

[0404] In some embodiments, upon receiving confirmation from the MSC (480) that the hook-and-flash protocol was successfully completed, confirming the generation of the CDR, the access control element (440) may communicate to the access control button (430) that the transaction was successful. Upon receiving an indication of success (e.g., a positive access permission indication), the access control button (430) may then change state, for example, presenting a positive icon, such as a check mark, to reflect that the payment was completed before unlocking access to the digital service or purchased content.

[0405] In some embodiments, upon successful completion of the transaction, the access control element (440) may then record the transaction amount to the access control platform in the cumulative access control wallet 499 (STAR ​​wallet) and record the amount payable to the provider (minus any interchange and processing fees) in an access control wallet associated with the provider (not shown).

[0406] In some embodiments, upon receipt of payment confirmation, the IAPP allows access to the requested content / service, completing the transaction. Thus, the access control element (440) can coordinate, transmit, and convert cellular signaling events into transaction events, synchronizing events on the IN 460 with those on the Internet. Thus, this signaling convergence seamlessly migrates cellular billing credentials to the cloud while maintaining authoritative transaction records in the form of CDRs.

[0407] In some embodiments, since device B (420) and device A (450) may be the same smartphone device, the user may not have to manually enter a star address signal (*NNN) to dial. Instead, 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 local or selected dialer on the phone device (420 / 450) and automatically enter an address signal corresponding to the price on the access control button 430. To automatically activate the dialer in this pre-addressed manner, the access control button (430) embedded in the web page may have an associated "tel:" reference, for example:

[0408] <a href＝"电话：*025”>*025 .

[0409] In some embodiments, when such a phone URL reference in certain embodiments opens a phone dialer with the address already entered, the user can then be asked to connect the call (e.g., by pressing a green phone button). Cellular apps with the necessary phone call control permissions and associated access control platform logic can exercise greater call control over the native dialer via the API, enabling one-click connections. Regardless, the typical time from clicking the access control button to completing the payment transaction is only a few seconds.

[0410] In some embodiments, the access control platform provides a virtual fingerprint payment system because the symbol key (470) (e.g., asterisk, hash, &, etc.) on the mobile phone A (450) is logically bound and synchronized to the expected, activated, individual access control button (430) on the Internet. The unique mapping between the symbol key and the access control button 430 allows access control platform transactions to be conducted simultaneously, uniquely signaled and switched, although each transaction can be presented uniformly and signaled nearly simultaneously. As above Figure 3 As described, this mass atomic binding between the symbol key and the access control button 430 is a function of the unique phase and expected signal, which is reflected in the access control platform transaction protocol.

[0411] In some embodiments, up to millions or more users may be viewing the same access control button controlling access to the same internet content on the same internet page, each user requesting the same cellular signal at essentially the same time, all independently and securely switched because each such button is uniquely and logically coupled, with a 1:1 relationship to a known and identified MSISDN from which the star signal originates. This secure digital cellular circuit ensures that when multiple cellular users are transacting simultaneously using an open protocol, A can never dial in and inadvertently pay B because their "cellular lines" never cross, so to speak.

[0412] In some embodiments, a bidirectional star button communication channel allows the access control platform to signal and visually alert the user. For example, if a user dials an incorrect series of digits to the access control element's expected digits, i.e., where the expected value [A:NNN] is not met, the button may "shake" (e.g., animating left and right) to indicate an incorrect payment attempt, thereby signaling the user to try again without incurring the cost.

[0413] [ Figure 4B ]

[0414] Figure 4B and Figure 4AThe shared annotation, except that the character "B" is appended to the numeric labels, is a channel representation of an IMS / VoLTE packet-switched telephony network (480B) and associated user equipment (450B).

[0415] In this IMS / VoLTE embodiment, the channel is logically connected to Figure 4A The same order and serial execution as described in , with the difference that applies to the elements depicted on the left side of unit WALLET (490), which can use SIP instead of ISUP signaling to set up calls, and can use SIP and DIAMETER instead of traditional SS7 / MAP protocols for account management and credit verification.

[0416] [ Figure 5 ]

[0417] Figure 5 A sequence of access control button conversions according to one or more embodiments of the present disclosure is shown. In the following sequence, it is assumed that the cellular MSISDN-A has previously been paired with the IAPP displaying the access control button 511.

[0418] In some embodiments, as above Figure 4A and Figure 4B The access button described and disclosed herein, as a self-contained user interface element communicatively coupled to an access control platform, overcomes a technical issue common to all transaction systems, which, in some embodiments, present a separate screen or dialog box for communication status. This separate user interface, with its switchable display context to convey transaction progress, is visually detrimental and operationally impactful to the user and the overall payment experience. The active, in-channel communication button disclosed herein, which encompasses all payment communications and status in a single user interface element, uniquely overcomes these current transaction design limitations.

[0419] In block u , the access control button 511 is partitioned into The item price is displayed, and the current icon (action / state) is displayed on the right (*). Upon loading, the access control buttons 511 enter an initial state, which in some embodiments is displayed as a series 512:

[0420] Color: Red, indicating that the transaction is stopped

[0421] Status: Locked, access to digital content / services is prohibited

[0422] Stage: Inactive.

[0423] Thus, 512 represents an inactive access control platform channel coupled with a locked digital item, sold for the listed price of 10 cents.

[0424] In some embodiments, upon activation of the access control button 511, such as by clicking or clicking the access control button, the series transitions to block 520, where the access control button 511 then establishes communication with the access control platform to set the payment expectation and, among other things, record the association between the cellular MSISDN-A and the payment amount, [A:010], as described above.

[0425] In some embodiments, it is desirable to further record and associate the provider and product identifiers for this button and the pending transaction, e.g. Figure 3 (Ledger 370) As described. During this communication establishment process, in some embodiments, the access control button 511 (now labeled 521) transitions to the (rotating) series 522:

[0426] Color: Orange indicates the status SHIFT

[0427] Status: Connecting

[0428] Stage: Anticipation.

[0429] In some embodiments, during this 520 transition, the button rotates from displaying the price on the left to displaying the address signal *010, indicating that the transaction currency is appropriate ($0.10), and displays a phone icon on the right. In one embodiment, the phone icon indicates that a dialing action is required. The color indicates that the button is in the signal SHIFT.

[0430] In some embodiments, the price and asterisks are displayed in the access button 511 ( and *) rotate or otherwise transition to display the reverse side of the button, displaying the dial string (*010) and the phone icon in the access button 521. In some embodiments, the transition intuitively synchronizes the conversion from the listed price to the dial string, showing a direct mapping between the dollar ($N.NN) digits and the previously displayed asterisk (*NNN) address signal.

[0431] In some embodiments, upon successful establishment of communication, access control button 523 transitions to series 523, which in this signaling embodiment displays:

[0432] Color: Green Signal GO

[0433] Status: Connected

[0434] Phase: Signal transduction.

[0435] In some embodiments, at this stage, the door button 521 can prompt the user to dial the displayed number. In some embodiments, this dialing action is performed manually when clicking the now green button. In another embodiment, the dialing action is automatically engaged when communication is successfully established.

[0436] In either case, when the device supports telephony, the dial action invokes and launches the native telephone dialer and automatically enters the dial string (*010), as described above in Figure 4. If the paired cellular device is physically different from the device displaying and showing the access control button, the user can manually enter the short dial string (*010) on the cellular telephony device (e.g., smartphone / mobile phone).

[0437] In some embodiments, upon dialing and thereby transmitting the desired access control platform address signal (*NNN), from the paired MSISDN-A, the access control platform is now communicatively coupled to the active and connected access control button, validating the transaction as described above. Upon successful completion of the transaction, the access control button 521 transitions to block 530. ， In some embodiments, block 530 rotates the access control button 531 again to display the original price on the left. 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, the transaction is signaled and completed within one second, as shown below. Figure 6 As described and shown in the 533 series, in this signaling embodiment, a completed transaction is visually confirmed:

[0438] Color: Blue, signals communication and transactions are completed.

[0439] Status: Unlocked, granting access to digital content / services

[0440] Stage: Traded.

[0441] In some embodiments, the final (blue) transaction state affirmatively "nods" yes to the user by animating the buttons in an up, down, and up sequence to indicate approval. In some embodiments, a sound byte may also be played at each transition to obtain an audible alert (e.g., the sound of a coin dropping into a glass tip jar). Upon successful payment, the screen will unlock to display the purchased items. In URL-driven content access embodiments, a successful payment may redirect the app / browser to the completion URL to display the unlocked content.

[0442] In some embodiments, if any error condition is encountered at any stage, the sequence may transition to block 540, where, in some embodiments, the button reverts to a red error state, showing the error encountered on the left (e.g., transaction timed out, incorrect number dialed, user canceled, etc.) and with a cross icon on the right. In some embodiments, the button may shake negatively with a left-right animation to signal a NO. Thus, the error sequence 544 may appear as follows:

[0443] Color: Red, if trading is stopped

[0444] Status: Error, indicating the reason

[0445] Phase: Cancelled, where the button can be reset.

[0446] In some embodiments, the access control button and the described series of transitions present a highly interactive, responsive, and inclusive payment signaling and processing channel. In some embodiments, the access control button is presented in an iframe that overlays the content so as to appear to float above the provider page.

[0447] [ Figure 6 ]

[0448] Figure 6 An example of a millisecond axis on a microtransaction exchange timeline for a access control platform is shown, highlighting a flash sub-second handover protocol according to one or more embodiments of the present disclosure. In some embodiments, the time (T) elapsed between exchange and billing elements is approximate for illustrative purposes, and the timeline is not drawn to scale. In some embodiments, handover and verification are measured in single-digit milliseconds.

[0449] T = 0 milliseconds:

[0450] At 610 , the user presses SEND to send an access control platform address signal (*NNN), encapsulating the disclosed transaction amount of $N.NN.

[0451] T = 10 milliseconds:

[0452] At 620, the cellular network performs AAA (Authentication, Authorization, and Accounting) procedures and, after passing the accounting check, verifies that the account associated with the caller has sufficient credit to sustain the $N.NN charge, and routes the call to the access control platform.

[0453] T = 20 milliseconds:

[0454] At 630, the access control platform verifies that the *NNN address signal received from the cell is from the expected MSISDN-A and matches the dollar amount on the access control button, and if that expectation is met, executes the WINK protocol, closing / hooking the call and then pausing for an appropriate period of time, e.g., one second or less, such as 500 milliseconds.

[0455] T = 520 milliseconds:

[0456] The access control platform returns the call ON / HOOK, generates a one-second cellular billing certificate for the signaled amount of $N.NN on the cellular network, and IN debits the certificate from the cellular wallet.

[0457] T = 521 milliseconds:

[0458] In some embodiments, the access control platform associates the access control platform's wallet with the access control platform and the provider wallet associated with each provider. The access control platform transaction is complete and the call ends (640). The total time is less than one second.

[0459] In some embodiments, the access control platform micropayment protocol can therefore facilitate payments that are exchanged over microseconds. Furthermore, because the access control platform payment protocol uses native telephone signaling channels, operates along the call setup and billing control path, and because it operates seamlessly using existing digital cellular wallets, the access control platform is invisible to the user (i.e., has a zero footprint) on any and all phones.

[0460] [ Figure 7 ]

[0461] Figure 7 An abstract charging view of a micropayment protocol for an access control platform disclosed according to one or more embodiments of the present disclosure is depicted.

[0462] Item 710 describes telephone device A transmitting a star address signal (eg, *NNN) to pay a transaction value of $N.NN.

[0463] Item 720 describes the OFF / ONHOOK toggle function (power icon) that is enabled when a billing check is passed, connects the call (OFF / HOOK), and then temporarily disconnects the call (return ON / HOOK).

[0464] Item 730 describes a charging function (positive / negative polarity) where the caller's cellular wallet is debited (-$N.NN) and the access control platform system and provider wallet are credited (+$N.NN, less any interchange and processing fees).

[0465] In some embodiments, the access control platform payment protocol can be similarly described by the following text diagram:

[0466] (*)– / \\ / –(+ / -), where:

[0467] (*) indicates star address signal (*NNN)

[0468] / \ indicates OFF HOOK status

[0469] \ / Indicates ON HOOK status

[0470] (+ / -) indicates wallet fee transaction (+ / -$N.NN).

[0471] [Figure 8]

[0472] Figure 8 is a flow chart describing prior art cellular billing. As shown in Figure 8, the user may be presented with multiple payment methods and is required to manually select the option they want. In process item 800, the IAPP indicates the purchase price of the content or service. The purchase price is an informational display, rather than an active payment user interface element, to inform the user of the transaction amount. In process item 801, the IAPP then presents multiple payment methods and displays the purchase price by presenting multiple payment buttons that are logically coupled to the item. In process item 802, the user selects the desired payment method by activating (e.g., clicking or tapping) the corresponding payment button. If the cellular mobile payment button is selected, the flow will move along the affirmative "yes" path to item 803. In process item 803, the IAPP executes the cellular billing method selected by the user.

[0473] In some embodiments, multiple payment options introduce manual decision points and hinder the mass adoption and frictionless flow of small payments because they are encountered frequently, thereby delaying cellular billing methods for low-value (micro) transactions.

[0474] [ Figure 9 ]

[0475] Figure 9 This is a process sequence for performing cellular micro-billing through an access control platform according to one or more embodiments of the present disclosure. In some embodiments, Figure 9 As shown in the sequence of FIG, embodiments of the present disclosure can eliminate manual payment selection by automatically selecting cellular billing for transactions below a maximum threshold amount. In some embodiments, a purchase price threshold of one U.S. dollar (USD) automatically selects and presents a cellular payment method button displaying a micro purchase price.

[0476] In flow item 900 , if the content or service purchase price is below a predetermined threshold, the flow will move along the affirmative YES path to item 901 .

[0477] In process item 901, the IAPP automatically switches the payment method to cellular and displays a cellular payment button showing the micro-purchase price. Therefore, whereas in the current state of the art, as described in FIG8 above, the IAPP can present and display the purchase price separately, given the existence of multiple payment methods, the disclosed micro-payment system and method presents a unified method and price in a single access control button, determining whether the price is below a maximum threshold.

[0478] In flow item 902, if the user activates an access control button (eg, a door controller interface element), the flow moves along the affirmative YES path to item 903, where the IAPP performs a cellular payment method.

[0479] [Figure 10]

[0480] FIG10 is a schematic diagram illustrating a prior art cellular billing interface.

[0481] IAPP screen 1000, showing content or service 1010 with a static (inactive) purchase price element 1011 ($9.99), separated by a dotted line, from a plurality of payment buttons and associated methods 1020-1030.

[0482] Multiple payment methods can include options such as: credit card (VISA), PayPal (PPAL), Apple Pay (APAY), Google Pay (GPAY), and cellular bill (CELL 1030).

[0483] Thus, the above diagram presents the user with a single item or service (1010) having multiple payment methods (1020), requiring the user to make a manual payment selection.

[0484] [ Figure 11A and 11B ]

[0485] Figure 11A and 11B An exemplary cellular micro-access control application programming interface (API) enabled by a access control platform implemented in accordance with one or more embodiments of the present disclosure is described. At least some embodiments of the present disclosure are capable of eliminating the manual payment selection requirement 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 programming interface that configures a single selection for a particular access-restricted item, the exemplary disclosed systems and methods of the present disclosure, at least in some embodiments, provide at least one technical solution consistent with website designs that, in certain embodiments, present multiple access-restricted content items, articles, links, and / or services per web page.

[0486] In some embodiments, as Figure 11A As shown, display screen 1100 thus displays a plurality of access-restricted items for purchase, each item being associated with a single, directly associated cellular payment access control button (e.g., access controller interface element) displaying a micro-purchase price that can be used as an access code. For example, item 1110 has access controller interface element 1111 for $0.99, item 1120 has access controller interface element 1121 for $0.10, item 1130 has access controller interface element 1131 for $0.25, and so on.

[0487] In some embodiments, as Figure 11BAs shown, display screen 1100 also displays a plurality of access-restricted items for purchase, each of which is directly associated with a single cellular payment access control button (e.g., an access controller interface element) displaying a micro-purchase price that can be used as an access code. For example, item 1110 has access controller interface element 1111A and a $0.99 access code label 1111B, item 1120 has access controller interface element 1121A and a $0.10 access code label 1121B, item 1130 has access controller interface element 1131A and a $0.25 access code label 1131B, and so on. In some embodiments, the access code label is displayed at, for example, but not limited to, a 1:1 ratio with the access controller interface element, thereby providing another technical solution for ensuring a single logical and visual relationship between the access code and the access controller interface element. In some embodiments, the access code label is displayed, for example, but not limited to, in visual proximity to an access controller interface element (e.g., a separation distance of less than 2 inches, a separation distance of less than 1 inch, a distance of less than 0.5 inches, a distance of less than 0.2 inches, etc.), thereby providing another technical solution that ensures a single logical and visual relationship between the access code and the access controller interface element.

[0488] [ Figure 12A ]

[0489] Figure 12A A micro-remuneration scheme using an access control platform is shown, wherein the IAPP allows users to access and consume content before requesting any payment in lieu of remuneration according to one or more embodiments of the present disclosure. In some embodiments, the IAPP screen 1200A displays content 1210A (e.g., item A) unlocked for consumption along with a cellular tip access control button 1220A. Thus, users can determine what value they derive from freely accessible content and what incentives, if any, they believe they should receive from the producer.

[0490] [ Figure 12B ]

[0491] Figure 12B A tip menu 1220B is shown for a micro-payment scheme using a portal platform according to one or more embodiments of the present disclosure. In some embodiments, the tip menu 1220B may present multiple micro-amounts upon activating (e.g., clicking / tapping) the tip access control button 1220A. The user may then select an amount to contribute to content production. In some embodiments, the IAPP may display the average or most common tip amounts to guide the user's selection. Upon selecting a tip amount, the cellular payment proceeds as disclosed.

[0492] In some embodiments, micropayment schemes invert the proposition of content commercialization, replacing it with an honor system where value can be freely determined by consumers and the market, rather than by producers.

[0493] [Figures 13A and 13B]

[0494] 13A and 13B illustrate alternative views of FIG. 10 and FIG. 11 , again highlighting at least one technical distinction between a technical deficiency and at least one technical solution, consistent with at least some embodiments of the present disclosure.

[0495] FIG13A illustrates a technical drawback of a circuit as a payment stack that presents multiple payment methods that the user needs to manually select. Figure 13B As shown, at least one technical solution of the present disclosure establishes an access control microcircuit that can display a single active channel 1310 that is automatically assigned, for example, but not limited to, when the purchase price is below a threshold amount.

[0496] [ Figure 14 ]

[0497] Figure 14 Graphically depicted is the relationship between frequency and size when multiple payment methods and options 1400 are presented for MACRO and MINI amounts versus a single cellular payment method 1410 presented for MICRO amount.

[0498] The lower frequency of MINI CELL transactions (e.g., $10) is primarily due to the fact that these transactions must compete with multiple more entrenched, well-known, and habitually used payment methods mentioned above.

[0499] High-frequency micropayments are predicted based on the positive psychological impact of a frictionless, single cellular payment method and ultra-low transaction values ​​(e.g., 10 cents).

[0500] MICRO Pay doesn't hinder users' choice of payment method. Instead, it seamlessly and quickly directs all small-value payments to fast cellular checkout lanes, removing all barriers to purchase decisions.

[0501] [ Figure 15A ]

[0502] Figure 15A An example of a custom rating model for an IN billing element is described, which is programmed to use a custom rating model to determine communication rates (charges) using address signals for calls according to one or more embodiments of the present disclosure. In some embodiments, the custom rating model can include a dynamically (continuously) calculated billing matrix that maps any Star-N address signal to its direct monetary value as follows:

[0503] Line 151A, the two *NN digits address signal a minimum / maximum fee of $0 / $0.99;

[0504] Line 152A, the three *NNN digital address signals resolve to a minimum / maximum fee of 0 / $9.99;

[0505] Line 153A, the four *NNNN digital address signals resolve to a minimum / maximum fee of 0 / $99.99;

[0506] Line 154A interprets the five *NNNNN digital address signals as minimum / maximum 0 / $999.99 fees;

[0507] Line 155A, any *N series digital address signal resolved to min / max Charge; and

[0508] Line 156A, any N-series up to 5-bit address signal resolved to min / max Charge.

[0509] In some embodiments, there may be a 156A bit limit, for example, a limit of up to 5. Such a limit, in some embodiments, is to ensure that the small payment address signal of non-star dialing does not intersect with the user's phone number space.

[0510] In some embodiments, the access control platform thus presents a highly transparent billing agreement to the user, as the dialed digits directly equate to the transaction cost, digit for digit.

[0511] In some embodiments, a user can dial any payment amount using the signaling methods and symbols described above. In some micropayment embodiments, a two-digit number (NN) enumerates and encapsulates payments between $0 and $1 ($0.01 to $0.99), which can implement technical solutions to the above-described technical problems, including efficient and verifiable microtransactions with authoritative records in the form of CDRs. In some embodiments, any other suitable number of digits can be used, for example, a three-digit embodiment (NNN) may be most suitable for clarifying the representation of dollars and cents, for example, 10 cents may then be represented as *010 rather than *10 to avoid any misunderstanding of the actual transaction value (for example, where *10 may be interpreted as representing $10).

[0512] [ Figure 15B ]

[0513] Figure 15BAdditional details are described for a custom rating model for an example IN element that is programmed to use a custom rating model to determine call rates using address signals for calls according to one or more embodiments of the present disclosure. In some embodiments, the custom rating model can present a static (discrete) micro-billing matrix or rating table that matches two (NN) or three (NNN) digit address signals to their direct monetary suitability.

[0514] Line 151B: Address signal *00 or *000 converts to a fee of $0.00;

[0515] Line 152B: Fee for converting address signal *01 or *001 to 0.01 USD;

[0516] Line 153B: Address signal *02 or *002 converted to a $0.02 fee;

[0517] Line 154B: Address signal *05 or *005 converted to a $0.05 fee;

[0518] Line 155B: Address signal *10 or *010 converted to a fee of $0.10;

[0519] Line 156B: Address signal *25 or *025 converted to a fee of $0.25;

[0520] Line 157B: Address signal *50 or *050 converted to a $0.50 fee;

[0521] Line 158B: Address signal *75 or *075 converted to a $0.75 fee; and

[0522] The address signal *99 or *099 on line 159B is converted to a fee of 0.99 USD;

[0523] Thus, a user can dial *01 (star zero one) to pay 1¢ from their cellular wallet. Similarly, a user can dial, for example, *02, *05, *10, *25, *50, *75, *99 to pay 2¢, 5¢, 10¢, 25¢, 50¢, 75¢, or 99¢, respectively. For larger amounts, users can dial longer matching digits, as described above. For more discrete amounts, users can dial the middle representative digits (e.g., (cents)).

[0524] In addition, in some embodiments, users can dial dollar normalization symbols, such as *001, *002, *005, *010, *025, *050, *075, *099 for matching denominations. In some embodiments, users can dial a short sequence of digits representing currency without a symbol (e.g., an asterisk) prefix, such as dialing 001, 002, 005, 010, 025, 050, 075, 099, where all such three-digit phone numbers can then be automatically converted to asterisks or numbers with appropriate prefixes by network switching and control elements in order to route them to such a small-value payment processing platform.

[0525] In some embodiments, the above-described billing modification is implemented by manually programming elements of the IN to populate an IN rating table stored in non-transitory memory with entries supporting the discrete small payment amounts (signals) allowed. That is, for each small payment offered by the IN (e.g., 1 cent, 2 cents, 5 cents, 10 cents, etc.), a new entry is inserted into the rating table corresponding to the address signals (e.g., rows) of these discrete small amounts. Therefore, in order to support the above table Figure 15B A small payment in , can program the elements of IN to add 9 new rows to the ratings table.

[0526] 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 signals, optical signals, acoustic signals, or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.).

[0527] In one or more embodiments, the IN billing system programmatically determines the nominal rate to apply by calculating an integer that fits the *NNN address signal. In one embodiment, the calculation may, for example, include:

[0528] 1) extract the NNN digits using string operations on the *NNN address signal to remove the sign prefix; and

[0529] 2) Use the PARSEINT type operation to convert the generated NNN string into an integer format, thereby generating the cent (NNN) represented by the *NNN address signal.

[0530] In some embodiments, when the exemplary STAR micropayment protocol is defined by a fixed three-digit notation (NNN), in a packet-switched network embodiment, the above-described conversion of signals to rates can be achieved by, for example, referencing a SIP URI / To String header and performing string operations as shown in the following JavaScript code:

[0531] parseInt(SIP_To.substring(1,4)).

[0532] In some embodiments, the string operations described above can be combined to extract the leading portion of the address signal that enumerates the charge to be applied without parsing any additional (meta)data that may be signaled for internal transmission to and interpretation by the access control platform. In one embodiment, the string function can extract the number signaled in part-2 of the multi-part signaling scheme, i.e., extract the number between the first and second asterisk (*) symbols disclosed herein, to enumerate the charge to be applied.

[0533] In some embodiments, the fees may be in a suitable currency. In some embodiments, the transfer of monetary value across the access control platform may be performed using a suitable currency, and the fees imposed by the IN may be in real / fiat / national currency.

[0534] In some embodiments, a user can dial any amount based on the above representation, for example, between $0 and $1 (including dialing *000 for a cost-free audit transaction), but the common denominations listed may be sufficient. One benefit of providing a set of discrete values ​​is to reduce the variance recorded and displayed in the phone's dialing history (e.g., a recent call list).

[0535] In some embodiments, a hook into the flash protocol can be used to pass transactions through the ring and transfer funds:

[0536] Sender: PLUS E.164[+MSISDN] Cellular Sender Wallet ([+A](or [A])

[0537] Recipient: B STAR[*MSISDN] Internet Receiver Wallet[*B].

[0538] In some embodiments, the receiving access control platform wallet is addressed according to the disclosed systems and methods, and in some embodiments, it utilizes the device registration and / or pairing techniques described above to identify and record the recipient MSISDN as an Internet content provider.

[0539] In some embodiments, the use of cellular and internet wallets enables fungible tokenization, which transfers and converts cellular network access (airtime) into internet content access (viewing time). In some embodiments, the use of cellular and internet wallets is facilitated by public symbol prefix signaling and exchange advancements that successfully migrate authoritative and irrevocable cellular billing certificates (CDRS) to the cloud. In some embodiments, CDR certificates are transferred to the cloud (Internet CDR certificates (ICDRS)), transforming the world wide web with micro-billing capabilities.

[0540] [ Figure 15C ]

[0541] Figure 15C The following table shows different address signal encoding schemes in some embodiments. In one circuit-switched network embodiment, address signals are transmitted in pairs as binary coded decimal (BCD) numbers (octets), with each signal represented in hexadecimal. ISUP address signals contain header information to define the total address length, whether the address contains an even or odd number of signals, and that odd-length addresses use BCD zero (0000) as padding.

[0542] Since such address signals are encoded in 4-bit hexadecimal notation, 16 discrete signals can be represented, and given that the decimal dial digits only require ten (0-9) permutations, as shown in lines 150C to 151C, the over-decimal signals describe the remaining six characters above the decimal digits, as shown in lines 152C to 157C.

[0543] In the telephone BCD notation embodiment, these over-decimal signals may represent the characters "*#ABC" and the stop (ST) signal by their BCD numeric equivalents (decimal digits 10-15). Thus, in the telephone BCD encoding embodiment, the asterisk (*) symbol may be encoded as the character "A" represented by hexadecimal (binary) 1010. In the natural BCD notation embodiment, these over-decimal signals may similarly represent the characters "ABCDEF," where F represents a terminated, address-completed, signal. Thus, in the circuit-switched network embodiment, the control or billing element may convert the 4-digit hexadecimal address signal to decimal integer representation, discarding any over-decimal signals, in order to extract and determine the charge to be applied.

[0544] In some packet-switched network embodiments, the address signal is encoded in 8-bit ASCII representation, such as represented by a SIP string in a SIP URI and a SIP To header. Therefore, in packet-switched network embodiments, the control or billing element may convert the 8-bit ASCII address signal to a decimal (integer) format in order to extract the enumerated charges.

[0545] [ Figure 16 ]

[0546] Figure 16 A flow sequence is shown describing a step for debiting a cellular wallet with a currency appropriate to an address signal, which then enables an Internet micropayment transaction to be completed in accordance with one or more embodiments of the present disclosure.

[0547] In the traffic item 1600, the network is based on the above Figure 15A and 15B The call setup request proceeds through the OBCSM and AAA (Authentication, Authorization and Accounting) steps, which determines whether the sender's (caller's) credit balance is sufficient to maintain the appropriate $N.NN charge disclosed.

[0548] In flow item 1610, if the caller has sufficient cellular credit to process the dialing transaction, flow proceeds along the affirmative YES path to item 1620. If the caller does not have sufficient cellular credit to process the dialing transaction, flow proceeds along the negative (NO) branch to item 1630.

[0549] In process item 1620, upon determining cellular credit sufficiency, the amount $N.NN is debited (or deducted) from the account associated with the caller, namely the CELL A wallet [A]. This basic step completes the cellular micropayment component of the Internet transaction and is implemented through HOOK FLASH (WINK) signaling as described above.

[0550] In process item 1630, regarding determining that there is insufficient cellular credit, in some embodiments, the network may play an error notification, such as, "You do not have enough 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.

[0551] [ Figure 17 ]

[0552] Figure 17 A flowchart for setting up access control platform expectations according to one or more embodiments of the present disclosure is described.

[0553] In process item 1700 , the IAPP requests an access control button using a published API communicatively coupled to an access control platform to control access to digital content or services priced at $N.NN.

[0554] In some embodiments, if the IAPP has previously identified and paired the MSISDN, this identification information will be passed into the API via a parameter.

[0555] In flow item 1701 , user A activates an access control button, such as by clicking or clicking the access control button.

[0556] In process item 1702, the access control platform checks whether the IAPP has communicated cellular identification information (e.g., the registration and / or pairing techniques described above). In some embodiments, if the X / MSISDN has not been communicated, flow proceeds along the negative NO branch to step 1703. If the X / MSISDN has been communicated, flow proceeds along the positive YES path to step 1704.

[0557] In process item 1703 , the access control platform performs registration and / or pairing techniques to securely determine the cellular identity.

[0558] In process item 1704, the access control platform sets the transaction expectation by recording (storing) the [A:NNN] entry in the data store or ledger. Thus, this record sets the expectation of receiving signal NNN from the phone device MSISDN-A, matching the activate access control button transaction from the registered and paired phone device.

[0559] [ Figure 18 ]

[0560] Figure 18 Describes an exemplary flow chart scheme for processing expected access control platform transactions, according to one or more embodiments of the present disclosure, according to the above Figure 17 set up.

[0561] In process item 1800, when the access control button is activated, the access control button can be operated as described above. Figure 5 The transition sequence described. In some embodiments, a transition may present a phone number to dial in order to conduct an access control platform transaction.

[0562] In this example, the access control platform transaction amount displayed in the access control button is listed as $N.NN, and according to the disclosed systems and methods, the button will be converted to display the *NNN dialing address.

[0563] In some embodiments, where the Internet device A and the telephone device MSISDN-A are the same device (eg, a smartphone), the user may click a button to activate the phone dialer on the telephone device.

[0564] In some embodiments, clicking the access control button thus causes the access control button to instruct the device to open a default or selected phone dialer and automatically enter the *NNN address signal. In some embodiments, where the phone device MSISDN-A is different from the internet device A, the user can manually enter the *NNN address signal to dial. Once the address signal is entered into the phone dialer, the user can press CONNECT (e.g., a green phone button) to initiate the call.

[0565] In some embodiments, upon receiving the call setup request containing the address signal, the cellular network performs AAA (Authentication, Authorization, and Accounting) procedures.

[0566] In process item 1811, the accounting verification determines whether the cellular wallet or account [A] associated with caller A has sufficient credit (based on the direct mapping of the disclosed signal to currency, $N.NN) to allow the call to be matured and routed to its destination. In other words, the call continues to be routed to the access control platform.

[0567] Thus, in some embodiments, access control platform calls are only allowed to be routed and reach the access control platform if the caller passes the necessary credit verification PIC (Point in Call). That is, the cellular account [A] associated with the caller is verified to contain sufficient funds to cover the currency listed in the disclosed address signal. Thus, all access control platform transactions are pre-approved and gated in accordance with established telephone accounting protocols that verify credit sufficiency before the call matures and is routed.

[0568] In some embodiments, if the balance of cellular account [A] is less than $N.NN, then based on the NNN address signal, flow branches along the negative NO path to flow step 1813, where in some embodiments, the network declares insufficient credit terms and terminates the call.

[0569] In some embodiments, if the balance of account [A] is greater than or equal to the $N.NN signal, traffic proceeds along the affirmative YES path to traffic item 1812, where the network is instructed to continue routing and place the call along a star path to the access control platform, as follows Figure 19A As stated.

[0570] In process item 1814, upon receiving the call setup request, the access control platform checks whether the expectation for the requested transaction exists and is satisfied. In other words, whether a record associating the MSISDN-A with the address signal NNN exists. If such an expectation exists and is therefore satisfied, the flow proceeds along the affirmative "yes" path to process item 1815. If no such expectation exists, the flow branches to the negative "no" path of item 1813.

[0571] In some embodiments, in addition to tying the intended caller MSISDN-A to a series of intended address signals (NNN), the micropayment expectation also associates and records the provider access control platform wallet [MSISDN-B] and SKU to identify the content or service controlled by the actively selected access control button with a price point of $N.NN. This reverse BA addressing expectation, set before the user issues the micropayment signal, enables the access control platform to tie the caller's Internet device to the content, the content consumer to the content producer, and process only matching, valid, active, and intended transactions to completion.

[0572] In some embodiments, it is desirable to ensure that if a user dials the incorrect price, by dialing a series of decimal digits that does not match the proactively displayed SKU price taught by the methods and systems disclosed herein, even if the user has sufficient credit to pay for the incorrectly dialed transaction, the access control platform can reject the call rather than accept it, so that no CDR is generated and no erroneous micropayment transaction is executed.

[0573] In some embodiments, matching incoming access control platform calls to the described expectations can enable technical improvements including reverse binding of providers and consumers, and preventing erroneous transactions from being made to the caller's account because if the transaction is not what is expected (intended), it will not be executed.

[0574] In some embodiments, when expectations are met, the access control platform instructs the network to play the RBT to the caller (not shown). Playing the RBT may sound confirmation that the transaction has been approved.

[0575] In flow item 1815, the access control platform performs a phone hook flash, which is a short OFF HOOK signaling event, and calls the OFF HOOK answer to start transaction recording.

[0576] In flow item 1816, the access control platform, in some embodiments, pauses, for example, between 500 milliseconds and 1 second, to produce a call duration of at least 1 second.

[0577] In process item 1817, the access control platform then returns the callback ON HOOK to complete the CDR recording.

[0578] In process item 1818, after successfully completing the above Figure 3 During the hook flash message protocol, the network records the CDR of the transaction, which debits the cellular account [A] for the $N.NN signal transaction amount, thereby completing the cellular portion of the transaction.

[0579] In process item 1819, upon receiving confirmation that the network successfully disconnected the call, the access control platform updates the access control platform ledger to reflect the successful payment, credits the Internet access control platform system [*] and the provider [MSISDN-B] wallet, and communicates the transaction completion to the access control button in accordance with the disclosed hook flash protocol. Upon receiving the successful transaction communication, the access control button may transition to a completed state (checked) and may unlock access to the purchased digital content or content and / or services, allowing the user to navigate to the content and / or services via the IAPP and / or web browser.

[0580] [ Figure 19A ]

[0581] Figure 19A is with Figure 3 The control scheme corresponding to the process method presented in more detail shows the sequential signaling steps of the small-value payment system and method disclosed in accordance with one or more embodiments of the present disclosure.

[0582] In-stream project 1900 middle, At access control element 1945, an Internet device 1948 requests access to digital content (1901) in the cloud, which requires payment and is therefore locked as shown. The content producer utilizes a suitable API to present an access control button (1902) on the display of the Internet-enabled device 1948, requesting payment at the listed price ($N.NN). In this example, it is assumed that the content provider has previously registered the associated MSISDN (B) as a provider identity, for example, using the registration and / or pairing techniques described above.

[0583] When requesting the access control button 1902, the access control button API is communicatively coupled to the access control element (1945), passing parameters describing the characteristics of the access control button 1902, including but not limited to, in some embodiments, the dollar amount, provider identity, SKU, button style, redirect URL for payment completion, etc.

[0584] In this schematic, it is assumed that an IAPP or browser providing Internet hosted content / services has been registered and paired with the cellular identifier MSISDN-A of user telephone device A (1940), as described above. In some embodiments, the pairing logically couples the access control platform volume presented in the access control button 1902, as displayed on the Internet device 1948, with the registered cellular identifier MSISDN-A, uniquely binding and stashing pending transactions.

[0585] Therefore, when receiving the metadata of the access control button 1902 through the API, the access control element (1945) sequentially sets (records) the above in the stream item 1910 of the access control element 1945. Figure 3 The payment expectation [A: NNN] is set by the access control ledger 1946. Although the schema depicts the access control button 1902 communicating directly with the access control element 1945, other access control platform elements may be associated and traversed in this communication. Thus, the access control button 1902 REQUEST causes the access control platform EXPECT to be set.

[0586] While the access control button 1902 request itself may facilitate this expectation, in practice, this expectation may be deferred until button activation (selection) because multiple access control buttons 1902 may be displayed. While a user may select multiple micropayment items for purchase, thereby creating a cumulative payment total (the sum of all selected items), this plural payment method may delay the expectation in order to record the expected total of pending transactions. The disclosed button presentation and state management method and system are described above. Figure 5 This is described in more detail in , which shows the button transition series in some embodiments.

[0587] In flow item 1910 at the access control element 1945, mobile device A (1940) dials the access control platform signal *NNN, sending a mobile origin (MO) call to the serving switching element (e.g., MSC) 1941. The setup message contains the *NNN address signal in addition to other call parameters. The MSC enters the OBCSM, which encounters the INITDP.

[0588] In process item 1920, INITDP establishes a call control dialogue between MSC 1941 and prepaid service control point (SCP) 1942. In some embodiments, the address of the dialogue is recorded in the SIM card original Camel subscription information (O-CSI) of MSC / VLR 1941.

[0589] In a Customized Application for Mobile Enhanced Logic (CAMEL) setting, the system can adopt standards that operate on a Global System for Mobile Communications (GSM) core network or a Universal Mobile Telecommunications System (UMTS) network. In the Camel O-CSI embodiment, the MSC 1941 has an associated gsmSSF (GSM Service Switching Function) and the SCP 1942 is called a gsmSCF (GSM Service Control Function).

[0590] SCP 1942 is configured to perform credit verification on user A, for example, by querying an online charging system (OCS) 1943 or a prepaid charging system to determine whether the account associated with device 1940 has sufficient credit to complete the call (i.e., a positive balance greater than or equal to $N.NN in this example). Although SCP 1942 and OCS 1943 are depicted as separate elements, they may be the same logical or physical element, they may contain additional charging elements, and they may contain both call and charging control logic.

[0591] In response to the credit verification check, OCS 1943 may respond to SCP 1942 in process item 1930 that the account associated with device 1940 has sufficient credit to complete the call. In response to the sufficient credit, SCP instructs MSC 1941 to proceed with the call.

[0592] It should be noted that although the figures in certain embodiments may illustrate the control and / or billing element issuing a CONTINUE command to instruct the switching element to continue routing and placing the call as per the original signal, in some network embodiments, the control or billing element may modify the address signal of the symbol prefix and subsequently issue a CONTINUE instruction with the modified parameters.

[0593] For example, in the above Figure 15C In the telephony BCD encoding scheme, an asterisk-prefixed address signal (e.g., *010) can be encoded and received by a network switching element as "A010." In some embodiments, the control and / or switching element can then convert the asterisk-prefixed address signal (i.e., the "*" address signaling prefix encoded as "A") and replace it with an internal short routing prefix RRR (e.g., 555), which defines the routing path to the access control element (e.g., a star-shaped access control platform). Typically, the short routing prefix contains 3 or 4 characters, which may themselves contain hexadecimal characters (e.g., 555A).

[0594] When the control or billing element converts and thereby modifies the original address signal sent by the cellular device, it can issue a CONTINUE instruction with modified parameters (i.e., using the modified CgPN address, e.g., 555010), thereby instructing the switching element to perform a routing lookup on the new internal routing prefix to determine the network routing path to the access control element.

[0595] In flow item 1940, in a symbol prefix signaling embodiment, MSC 1941 performs a routing lookup on the star prefix in the address signal to determine the relay / route to the access control element 1945, which can be hosted in the cloud, and sends an ISUP IAM (Initial Address Message) to the GMSC / SBC 1944, which establishes the mobile originating (MO) segment 1999.

[0596] The GMSC / SBC 1944 (or media gateway controller) is configured to interwork between Signaling System 7 (SS7) and IP networks and, in some embodiments, to perform signaling conversion between ISUP and SIP (Session Initiation Protocol). During the ISUP / SIP conversion, the ISUP IAM is converted to a SIP INVITE, which is then transmitted to the access control element 1945.

[0597] ISUP includes messaging protocols such as IAM and is part of SS7, used to set up telephone calls in the Public Switched Telephone Network (PSTN). The Mobile Application Part (MAP) is an SS7 protocol that provides an application layer for GSM and UMTS mobile core networks, as well as the General Packet Radio Service (GPRS) core network, to set up and control calls over the PSTN for communications and services between mobile users. Telephone exchanges (e.g., switches) can be connected via T1 or E1 trunks as a shared communication line path to carry voice from the call.

[0598] SIP is a signaling protocol used to initiate, maintain, and terminate real-time multimedia (e.g., voice, video, and / or messaging) sessions for Internet telephony applications and / or instant messaging over Internet Protocol (IP) networks and / or Voice over IP (VOIP) networks.

[0599] In flow item 1940, upon receiving the SIP INVITE, the access control element 1945 queries the access control ledger (1946) to determine if the access control platform transaction for the device MSISDN-A (1940) transmitting the NNN address signal is expected (already set) and now matches (satisfied).

[0600] In process item 1950, upon matching the expected transaction, in some embodiments, as indicated by the parentheses, the SIP 180 / RINGING message is optionally responded to backward, instructing the GMSC / SBC 1944 to return an ISUP Address Completion Message / Call Progress (ACM / CPG) alert message, notifying the MSC 1941 that the transaction has been connected to the access control platform. In turn, the MSC 1941 may optionally present the RBT to the mobile device 1940, as shown in the figure (BELL). Upon responding to the SIP / 180 as a RINGING message, the access control element 1945 matures the call into a placed and completed call, thereby providing a successful call setup.

[0601] The SIP / 180 response is optional because it does not materially impact the access control platform protocol, which is based on the disclosed WINK (hook flash) signaling to perform the transactions described below, and further because the user experience of the access control platform is visually communicated through the access control button 1902 in the disclosed IAPP.

[0602] 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) back which is converted at the GMSC / SBC 1944 into an ISUP ANS (ANSWER) message. ， Notify MSC 1941 that the call has been answered. At this point, the call is off-hook (connection binary <1> ), as shown in text in flow step 1960 and indicated graphically in 1961, and a call duration timer begins for CDR generation associated with the answered call.

[0603] In flow item 1970, access control element 1945 thereafter, in some embodiments, between 500 milliseconds and 1 second later (or any other suitable time period), disconnects the call by issuing a SIP BYE command backward, which GMSC / SBC 1944 converts to an ISUP REL (Release), instructing MSC 1941 to release the call, and the call returns to the ON HOOK state (DISCONNECT BINARY <0> ), as shown in the text in the flow step for the graphs for 1970 and 1971.

[0604] Thus, this Star mobile hook flash signal is directed by the access control element 1945 to raise the receiver to OFFHOOK (i.e., answer), and then, in some embodiments, after 500 milliseconds to 1 second (or any other suitable time period), switches the receiver back to ON HOOK (i.e., release).

[0605] In process item 1980, on the network where the call is successfully disconnected, the MSC 1941 responds in the forward direction with an ISUPRLC (release complete), which is converted into a SIP 200 message at the GMSC / SBC 1944 and transmitted to the access control element 1945, completing the STAR RING HOOK FLASH, or STAR HOOK FLASH (no RBT presentation) payment protocol (block 1991).

[0606] In process item 1990, when issuing ISUP RLC, MSC 1941 completes the generation of CDR, thereby recording a nominal call duration event (e.g., one second), thereby obtaining payment from the caller according to the disclosed micropayment method. (cents) are debited from the relevant account.

[0607] In some embodiments, this mobile initiated dialog, collectively referred to herein as a "ring hook flash" (or "hook flash") signaling protocol (block 1991), can provide caller A with an instant ring followed by an instantaneous call connection and disconnection (OFF / ON HOOK), thereby placing and dropping the call to present a call duration of 00:00:01 seconds on the display screen of device A 1940. This hook flash signaling protocol and clearing provides audio-visual confirmation that the transaction was successfully completed.

[0608] The network confirms that the hook flash transaction has completed and the CDR has been recorded upon receipt of the SIP 200 in flow item 1980 in response to the SIPBYE message issued by access control element 1945 in flow item 1970. This confirmation confirms that the account associated with device 1940 has been debited with the $N.NN micropayment and that the cellular portion of the transaction has been successfully completed.

[0609] If the device 1940 disconnects the call before the hook flash signal is complete, 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 cannot be completed. In such a scenario, in some embodiments, the access control element 1945 communicates the transaction failure to the access control platform button 1902 / 1982, which can then change state to reflect the occurrence of a "CANCEL" event (not shown).

[0610] In process item 1980, in response to the successful completion of the cellular transaction, the access control element 1945 updates the LEDGER 1946 to record the successful completion of the micropayment transaction, crediting the corresponding $N.NN amount to the access control platform's own wallet (system wallet) [*] and crediting the transaction amount ($N.NN) to the provider access control platform wallet [*B] less any interchange and processing fees that may apply (neither of which are shown).

[0611] In process item 1981, the access control component 1945 then communicates a successful RESPONSE to the access control platform button 1902. In some embodiments, a successful RESPONSE may cause the access control button 1902 to change state to reflect the PAID (1982), which in turn unlocks the digital content and / or service (1983). ) For access by device 1948.

[0612] When the RBT and hook flash, audio and video feedback can be provided to the phone. The user experience of the main access control platform is presented in the access control platform button because it is converted under the signaling, status management and control of STAR 1945, as shown above. Figure 5 As stated.

[0613] [ Figure 19B ]

[0614] Figure 19B is with Figure 3 The control scheme corresponding to the process method presented in more detail shows the sequential signaling steps and methods for a small payment system for an original VoLTE call request according to one or more embodiments of the present disclosure. Figure 19B and Figure 19A Share corresponding labels and steps, except for flow items marked with the letter B. Figure 19A describes a circuit-switched framework and associated mobile phone equipment 1940, Figure 19B Describes the VoLTE telephone user equipment (UE) that accesses packet-switched networks 1941B / 1942B 1940B In this control mode, local SIP signaling functions between UE 1940B, IMS network elements 1941B and 1942B, and access control platform 2 are described.

[0615] In some embodiments, the communication 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 packets based on a destination address to transmit messages.

[0616] SIP is a signaling protocol used to initiate, maintain, and terminate real-time multimedia (e.g., voice, video, and / or messaging) sessions for Internet telephony applications and / or instant messaging over Internet Protocol (IP) networks and / or Voice over IP (VOIP) networks. UEs may include intelligent or other 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 incorporate circuit-switched networks based on dedicated point-to-point connections for calls, as described below.

[0617] Packet-switched networks group data so that it can be transmitted as packets (e.g., discrete blocks of data) over a digital network. As mentioned above, one such packet-switched network may be IMS VoLTE, which utilizes the Internet Multimedia Subsystem (IMS) and packet-switched voice services for Voice over Long Term Evolution (VoLTE), a high-speed wireless communication for mobile phone devices and data terminals, such as other smart mobile devices that may be on an Internet of Things (IoT) network.

[0618] IMS VoLTE uses VoLTE as a high-speed wireless communication protocol, leveraging 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)) can be converted into network packets before being broadcast over public switched networks such as IM VoLTE. VoLTE uses an IMS-based network to deliver these services. Among other services, VoLTE supports rich multimedia communications, including high-definition audio and video services, which can run over both 4G and LTE data networks.

[0619] The IMS resides as a standalone system outside the VoLTE network and can be communicatively coupled to the VoLTE network via an interface with the VoLTE network gateway (e.g., the SGi interface that connects the IMS to the Public Data Network (PDN) gateway, as described below). One or more UEs can be communicatively coupled via the Evolved University Telecommunications System Terrestrial Radio Access Network (E-UTRAN) and the Evolved Packet Core (EPC) interface of the VoLTE network, and further communicatively coupled to IP services such as the IMS network and the Internet. E-UTRAN is a radio access network that serves as the air interface for the 3rd Generation Partnership Project (3GPP) LTE IN upgrade path.

[0620] The EPC of a VoLTE network may include functional elements such as the Mobility 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 flows IP packets in uplink and downlink transmissions and handles handovers. The PDN Gateway assigns IP addresses to UEs and acts as a communication point between EUTRA and other non-3GPP services such as the Internet. Respective PDN Gateways can be associated with the IMS and the Internet and provide interfaces such as the SGi interface, which serves as a reference point between the PDN Gateway and the packet data network.

[0621] The EPC may further include a Policy and Charging Rules Function (PCRF) element as a functional element to determine in real time the type of traffic allowed and the traffic accounting for billing purposes. When the UE initiates a VoLTE call, the PCRF may check whether the UE has a subscription for initiating the call, and if so, set up a dedicated bearer for the IMS service. An IMS-driven UE may include a Universal Integrated Circuit Card (UICC) and a Session Initiation Protocol User Agent (SIP UA) for sending and receiving SIP messages and providing telephone functionality. The UICC may include identity modules, such as a User Identity Module (SIM) and an IP Multimedia Services Identity Module (ISIM), for use by the IMS subsystem.

[0622] Many elements can comprise an IMS / VoLTE packet-switched network; however, for simplicity, IMS / VoLTE will be referred to herein as a broad SIP network subsystem. Furthermore, the key functional elements of the VoLTE architecture described herein can be defined within 3GPP, while also allowing non-3GPP technologies to interface with and be managed by the IMS VoLTE network. The IMS functional elements of the IMS core can include the Proxy Call Session Control Function (P-CSCF) and the Serving Call Session Control Function (S-CSCF).

[0623] The P-CSCF may be the initial point of contact for IMS-enabled VoLTE user equipment (UE) session signaling. The P-CSCF may act as a SIP proxy by forwarding SIP messages between the UE and the IMS core network.

[0624] The S-CSCF includes data related to user knowledge and application permissions associated with user accounts. The S-CSCF of the IMS Core can provide session, routing, and charging functions for all sessions under its control and call application servers based on the initial filter conditions (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) whose user account is assigned to it by the HSS and the Interrogating Call Session Control Function (I-CSCF). The S-CSCF can query the HSS for user profiles for authorization and management of requested services.

[0625] Therefore, the S-CSCF may be a core element in the IMS signaling plane. The S-CSCF may be a SIP server that also performs session control and, in some embodiments, downloads and uploads user profiles associated with user accounts to and from the HSS using the Diameter Cx and Dx interfaces. The S-CSCF may also handle SIP registrations and sit in the signaling path for all messages. In at least some embodiments, the S-CSCF may determine to which application server (AS) SIP messages from the UE's SIP UA, processed by the P-CSCF, will be forwarded to provide services and provide the necessary routing.

[0626] The S-CSCF can therefore allocate an AS for a session when required. In some embodiments, the role of the S-CSCF is to execute the session request by locating the target endpoint and conducting signaling to it. The S-CSCF can also coordinate with the Media Resource Function (MRF) to play any media announcements / tones to the initiator. According to the 3GPP technical specifications, the S-CSCF can also act as a Charge Trigger Function (CTF), managing the charging of the IMS infrastructure and service users. The S-CSCF can communicate with the IMS Gateway Function (IMS-GWF), which can run as a SIP application server and can signal the S-CSCF to terminate the session when the user runs out of credits during a session. Although the S-CSCF can act as a CTF, the same functionality can be applied to any IMS network element.

[0627] In an embodiment, as a CTF element in an IMS network, the S-CSCF can perform several tasks to identify the correct charging to apply, which corresponds to and is triggered by user session activity. The S-CSCF, while performing normal routing operations of SIP signaling, can determine whether a SIP message represents a chargeable activity and which type of charging mechanism can be applied. The charging mechanism for an IMS session can be offline (postpaid) charging, which uses accounting messages, or online (prepaid) charging, which uses essentially real-time credit control messages and procedures. Information about the IMS transaction can be sent from the S-CSCF to the charging element, which collects this information and stores it in a charging data record (CDR).

[0628] In process item 1910B, user A, using VoLTE UE device 1940B, dials address *NNN, representing a micro-transaction of $N.NN, in accordance with the disclosed methods and systems. This dialing causes UE 1940B to send an INVITE request to P-CSCF 1941B, whose address was discovered during the UE registration process (not shown). The INVITE request may include the IMS Communication Service Identifier (ICSI) for IMS multimedia telephony (e.g., urn:urn-7:3gpp-service.ims.icsi.mmtel) in both the Contact header and the P-Preferred-Service header.

[0629] In flow item 1920B, P-CSCF 1941B adds a P-Charging-Vector header and forwards the SIP INVITE to S-CSCF 1942B (not shown) identified during UE registration. S-CSCF 1942B receives the SIP INVITE from P-CSCF 1941B. 。 The S-CSCF 1942B invokes any VoLTE services defined and triggered by the Initial Filter Criteria (IFC) in the user profile, retrieved during IMS registration. The S-CSCF 1942B checks the P-Preferred-Service header (e.g., MMTel ICSI) in the SIP INVITE request and verifies that the user is authorized for the service by validating the subscribed services retrieved in the service profile during registration.

[0630] For example, with online charging, the OCS can grant network resource usage based on the price or tariff of the requested service and the balance in the user's account. The OCS can support at least two types of online charging functions: session-based charging function (SBCF) and event-based charging function (EBCF). The SBCF may be responsible for network bearer and session-based services, such as voice calls, GPRS sessions, or IMS sessions. In addition, after checking the subscriber's account, it can control the session by allowing or denying the session establishment request. In the OCS, the rating function (RF) can determine the price / tariff of the requested network resource usage in real time.

[0631] In flow item 1920B, P-CSCF 1941B may respond to the requesting UE 1940B with a SIP 100 TRYING to prevent the INVITE from timing out. P-CSCF 1941B may then forward the INVITE to S-CSCF 1942B, which in turn may send an initial credit charge request (e.g., CCR CC request type "INITIAL_REQUEST") to OCS 1943. OCS 1943 may be collectively referred to as a Session Balance Control Function (SBCF) and an Account Balance Management Function (ABMF).

[0632] In process item 1920B, upon receiving the CCR message, the SBCF may retrieve the account information and subscriber profile from the OCS ABMF. The SBCF may then send a Rate Request message to the RF to determine the rate for the IMS call. Based on the user information, the RF may reply to the SBCF with a Rate Response message, which may include the billing plan and rate information for the IMS service.

[0633] After receiving the tariff information, the SBCF may make a credit unit reservation with the ABMF. It may then reply to the S-CSCF 1942B with a Credit Control Answer (CCA) message containing any credit granted (e.g., specifying the number of seconds or minutes allowed for the call). When it has been determined that the account associated with user A has sufficient credit, in this embodiment greater than or equal to $N.NN, the CCA message returned in process item 1930B may indicate that the credit authorization was successful.

[0634] In process item 1930B, in some embodiments in response to receiving the CCA successfully, the S-CSCF 1942B or accompanying TAS may then reroute the INVITE request with the modified call signal (e.g., *NNN@) to the IP address of the access control platform 1945 as the transaction processing platform via the SBC 1944.

[0635] In flow item 1940B as shown, in response to receiving the CCA successfully, the S-CSCF 1942B or accompanying TAS may therefore create a new call leg on the modified INVITE request, including the modified call signaling with the modified address, the differentiated services code prefix and the signaling switch target address.

[0636] In an embodiment, the modified address incorporates a differentiated services code (e.g., * or XXX) prefixed with the B-address signal and is designated as a network identifier for the micropayment access control platform target address, with the star domain specified in the branch URI. As a non-limiting example, the modified address may take the following form:

[0637] Invite sip:*NNN@starlogik.com SIP / 2.0 or,

[0638] Invite sip: 555NNN@55.225.225.45SIP / 2.0,

[0639] Where 555 is the service code prefix of the application, and 55.225.225.45 is the IP address of the Starry Sky access control platform (IPV4 notation).

[0640] The S-CSCF 1942B may then add a Via Header with the new branch tag, thereby branching (forwarding or sequentially forking) the call through the SBC 1944 to the access control platform 1945 in some embodiments.

[0641] The symbol-prefixed URL may further include the Mobile Network Code (MNC) and Mobile Country Code (MCC) assigned to the Mobile Network Operator (MNO), for example:

[0642] Invite sip:*NNN@7.655.starlogik.com SIP / 2.0.

[0643] The above INVITE example illustrates the DNS URL for MNO Cell C in South Africa (MCC=655 is the country name for South Africa and MNC=7 is the network identifier for the MNO. The MNC level 4 and MCC level 3 domains allow for dynamic DNS resolution of fully qualified domain names (FQDNs) specific to the country and operator to enable localized access control platform hosting.

[0644] According to the call data record generation swap disclosed herein, the original CDRS used for the Ring Commerce Uplink method (block 1991) can generate a CDR. In some embodiments, the CDR is recorded along with the MSISDN-A and the address signal *NNN (A*NNN). Therefore, as described above, the INVITE request is branched using the modified NNN address signal, preserving the reconciliation of the CDR with the micropayment transaction being conducted.

[0645] This NNN address signal modification can ensure that the access control element 1945 performs the above Figure 19A The hook-and-flash method described herein generates raw S-CSCF CDRs. In process item 1960B, STAR 1945 goes OFF HOOK (answering the call) and then, for example, between 500 milliseconds and 1 second, or another duration of nominal call length, thereafter returns ON HOOK (hanging up the call) in process item 1970B, collectively referred to as service block 1991, distinguishable as A*NNN (or XXXNNN) titled CDRS. Such A*NNN-generated CDRs (e.g., STAR CDR datasets) can then be audited to calculate the cumulative access control platform transactions conducted over a set time period.

[0646] Therefore, traffic items 1940B to 1980B communicating with the access control platform 1945 are functionally suitable for Figure 19A Traffic items 1940 to 1980 in the flow, however, since the described IMS / VLTE packet switching network can utilize SIP signaling, signaling protocol conversion between UE 1940B and IMS network elements (P-SCSF 1941B and S-SCSF 1942B) and access control platform 1945 is not required in this embodiment.

[0647] [ Figure 19C ]

[0648] Figure 19B is with Figure 3 The control scheme corresponding to the process method proposed in more detail shows the sequential signaling steps of the small-value payment system and method disclosed in one or more embodiments of the present disclosure. Figure 19C and Figure 19A Similar to Figure 19A Share the corresponding tags and steps, such as Figure 19A As shown, except for those mobile items which are designated with the letter C. There is no symbol prefix.

[0649] In process project 1930C ，SCP 1942, in some embodiments associated with OCS 1943, automatically modifies received NNN address signals when such signals contain a sequence of digits between a minimum and maximum, e.g., between a minimum of 3 digits and a maximum of 5 digits, to include a routing prefix identifying access control platform 1945.

[0650] In flow item 1930C, upon modifying the NNN address signal, SCP 1942 instructs MSC 1941 to CONNECT the call to 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 through a gateway MSC (GMSC) or media gateway controller (MGC), neither of which are shown, and in some embodiments, through SBC 1944 to access control platform 1945. The MGC / SBC may perform the conversion of the ISUP IAM to the SIP INVITE signaling protocol, as disclosed herein.

[0651] In traffic item 1930C, MSC 1941 may look up a preconfigured routing table, including a trunk indicator (e.g., a trunk communication path) associated with the modified address signal prefix, and convert / route the modified address based on the trunk indicator associated with the modified address in the preconfigured routing table. The modified call signal may be automatically routed from MSC 1941 along the trunk to GMSC / MGC or SBC 1944, and then automatically routed along the SIP trunk to access control platform 1945. The disclosed micropayment transaction is then processed according to Figure 15A Proceed as described above.

[0652] [ Figure 20 ]

[0653] Figure 20 An illustrative, non-limiting example is described of a process based at least in part on mobile communication signals, based at least in part on some embodiments of the present disclosure. In some embodiments, the process includes an access control platform 2000, for example, implemented as a cloud platform, interfacing with a cellular network 2030 to conduct transactions using CDRs.

[0654] In some embodiments, mobile phone 2020 can be associated with a network account (wallet not shown) on cellular network 2030. In some embodiments, phone device 120 can communicate with cellular network 2030 to transfer value from the network account to access control platform 2000 to access digital goods and / or services 2040 for delivery to phone device 2020. In some embodiments, phone device 2020 communicates the request for value transfer by formatting the address signal of a phone call to carry the value to be transferred.

[0655] In some embodiments, the access control platform 2000 is configured to interface with a cellular network 2030. Thus, the cellular network 2030 can provide value from an account on a phone device 2020 to deposit virtual tokens into an access control platform wallet 2010 associated with a digital goods and / or service provider 2040. In some embodiments, the virtual tokens can include authentic, transparent, low-cost, fiat-backed micro-currencies. By providing virtual tokens to the provider's access control platform wallet 2010, the access control platform 2000 can provide value for digital goods and / or services 2040, allowing them to be distributed to the phone device 2020. Thus, adapting the cellular network 2030 can democratize internet commerce and access to digital content and / or services.

[0656] Artisans skilled in switching and billing will appreciate that alternative embodiments may include those that combine metadata with the dialed digits enumerating the appropriate currency, where such metadata may include, without limitation, data identifying the beneficiary and stock keeping unit (SKU).

[0657] While some embodiments may include the use of a hook flash protocol where a phone call is temporarily closed and then returned to hook to execute the transaction, and where an address signal enumerates the transaction amount, other network protocols and bearers that provide appropriate transaction functionality may be employed, including but not limited to USSD and SMS bearers.

[0658] In another USSD embodiment, the following mobile-originated dial string can achieve a similar result:

[0659] *NNN# or *XXX*NNN#.

[0660] The above USSD example can also be interpreted as requesting a transaction with a currency of $N.NN matching the signal NNN, and the XXX code can identify the USSD application providing the service for the transaction, which is typical in USSD service provisioning. USSD command strings in some embodiments use asterisks as delimiters to separate variables.

[0661] For example, the following USSD dial string can be constructed to encapsulate the alternative small payment application XXX, the currency appropriate amount NNN, the provider identifier PPP, and the product SKU CCC being purchased:

[0662] *XXX*NNN*PPP*CCC#.

[0663] In the USSD example above, PPP and CCC may be the digits or numbers required to uniquely identify the provider and the item being sold. Similarly, NNN may be the digits required to enumerate the applicable currency, with higher digits representing higher-cost items. In another USSD embodiment, the USSD string may encapsulate (merge) the multi-part address signals disclosed herein. In yet another USSD embodiment, a small payment application may be identified by a leading zero as:

[0664] *0NN#, that is, $0.NN and

[0665] *0NNN#, translated into $N.NN.

[0666] In some embodiments, the USSD command string embodiment starting from zero (prefix) may compress the USSD application identifier (which in some embodiments is three digits) into a single identifying digit and a leading digit (zero) to present a simplified USSD command set that enumerates the transaction amount, as in the telephone embodiment described herein.

[0667] USSD application hosting, routing and / or execution can be provided by the network internally using protocols such as Mobile Application Part (MAP) signaling, and externally using an external messaging entity connected to the operator's USSD and / or SMSC messaging platform, using standard Internet protocols such as SMPP and HTTP.

[0668] In an SMS micropayment embodiment, the systems and methods disclosed herein may be implemented by allowing users, and by proxy, their mobile devices to send payment instructions to an SMS short address code that itself enumerates the transaction amount.

[0669] The SMS signaling path and billing process in an intelligent network (IN) may be similar to the disclosed symbolic prefix telephony protocol. By modifying SMS routing (e.g., CdPA-based message interception and routing) and by modifying the billing system according to the above-described telephony system and method, all such symbolically addressed mobile-originated messages can be used for the disclosed cellular micro-billing, i.e., the amount enumerated in the SMS address is deducted from the account associated with the sending mobile device and then routed to an access control platform (e.g., the disclosed DCB platform) with the symbolic address prefix to complete the Internet transaction.

[0670] For example, to allow SMS to be sent to the following addresses:

[0671] *NNN.

[0672] Since many mobile devices allow SMS to be sent under the programmatic control of the IAPP behind the scenes without user intervention, this symbol-prefixed SMS signaling service will provide a similarly engaging and frictionless user experience. Furthermore, since SMS messages sent by users lacking sufficient credit may be immediately rejected (e.g., the operator returns MO_FSM_Neg_Response), the device may be alerted to the submission failure, thereby preventing the content from being accessed and preserving the interactive real-time signaling features displayed during the transaction, as disclosed using the telephone agreement.

[0673] As mentioned above, Premium Rate SMS services have not yet managed to transparently reflect the fees to be charged, as the PSMS short address code does not encapsulate or indicate the cost of the service in any way. In addition, many PSMS services require different short codes for different amounts.

[0674] By allowing consumers to conduct transactions disclosed herein using SMS signaling services prefixed with a symbol, the PSMS platform can be modified to overcome this billing and marketing limitation by accepting universal signaling and encapsulating the service cost (the charge to be applied) within the symbol-addressed mobile-originated SMS header. Existing PSMS platforms utilize two-way mobile-terminated SMS messaging, which consumes more network resources (i.e., paging and locating the target device, then transmitting a return reply confirmation), whereas the newly disclosed mobile-terminated SMS transactions can be conducted in a single step without necessarily requiring any SMS confirmation content in the message body, as the original message authoritatively instructs the operator to apply the signaling charge. Short messages sent without a content payload reduce the signaling load on the network.

[0675] Furthermore, as discussed above, such a cellular message signaling system would satisfy the data requirements for what constitutes a "card present" transaction, as a mobile-originated SMS message addressed in this manner would generate an authoritative, irrevocable billing record capturing the transaction data and cost at the time of submission.

[0676] For example, sending a STAR SMS from a mobile terminal may result in CDR, as shown in Table 4.

[0677] Table 4.

[0678]

[0679] In some embodiments, making payments on the Internet requires a user to log into an exemplary access control platform of the present disclosure, for example by entering a registered username and password, and typically authorizing the transaction via a two-factor code (2FA). Thus, the disclosed embodiments can improve online payment processing by leveraging existing biometric and other protections used to lock mobile phones, thereby preventing unauthorized access to the phone and, therefore, to small payment functionality, without relying on vulnerable network communications for authentication.

[0680] 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., a laptop, tablet, etc.), these existing device protections 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 small payment may not only enhance the user experience, but may also lead to high-frequency utilization. In some embodiments, the exemplary computer-based invention system / platform, the exemplary computer-based invention device, and / or the exemplary computer-based inventive component may be configured to handle a number of concurrent users, including, but not limited to, at least 100 (e.g., but not limited to, 100-999), at least 1,000 ( For example, but not limited to, 1,000-9,999), at least 10,000 (e.g., but not limited to 10,000-99,999), at least 100,000 (e.g., but not limited to 100,000-999,999), at least 1,000,000 (e.g., but not limited to 1,000,000-9,999,999), at least 10,000,000 (e.g., but not limited to 10,000,000-99,999,999), at least 100,000,000 (e.g., but not limited to 100,000,000-999,999,999), at least 1,000,000,000,000 (e.g., but not limited to 1,000,000,000,000,000).

[0681] [ Figure 21 ]

[0682] Figure 21 An illustrative, non-limiting example is described that is based at least in part on mobile communication signals consistent with at least some embodiments of the present disclosure. In some embodiments, Figure 21The exemplary process may include at least the following steps: in step 2101, the processor of the computing device receives at least one application instruction through the application and the communication network to display the access controller interface element and the access code on the screen of the computing device; wherein the access controller interface element is: communicatively coupled to the cellular network hosting access control architecture and operatively linked to the access-restricted digital resource; in step 2102, the processor of the computing device executes at least one application instruction to display the access controller interface element and the access code on the screen of the computing device; in step 2103, the processor of the computing device detects at least one activity associated with the access controller interface element; in step 2104, the processor of the computing device sends, based on Detection of at least one activity with a request for access to data, the data comprising: an access code and an identity linked to a computing device; wherein at least a portion of the data is configured to be accepted by a cellular network hosted access control architecture; at step 2105, receiving, by a processor of the computing device, in response to the access request sent and through an application, at least one access program instruction to unlock an access-restricted digital resource for access through the computing device; wherein receiving the at least one access program instruction to unlock the access-restricted digital resource is after the cellular network hosted access control architecture accepts at least a portion of the data; and, at step 2106, executing, by the processor of the computing device, the at least one access program instruction to unlock the access-restricted digital resource for access through the computing device.

[0683] [ Figure 22 ]

[0684] Figure 22 An illustrative, non-limiting example is described that is based at least in part on mobile communication signals and at least in part on some embodiments of the present disclosure. In some embodiments, Figure 22An exemplary process may include at least the following steps: in step 2201, the processor of the access control server sends at least one application instruction to the computing device through the application and the communication network to display the access control controller interface element and the access code on the screen of the computing device; wherein the access control controller interface element is: communicatively coupled with the cellular network hosted access control mode and operationally linked to the access-restricted digital resource, restricting access through the computing device; in step 2202, the processor of the access control server receives an access request based on at least one activity associated with the access controller interface element; wherein the access request has the following data: an access code and an identity linked to the computing device; in step 2203, the processor of the access control server queries, based on at least a portion of the data, the cellular network hosted access control mode for affirmative access permission indication; wherein at least a portion of the data is configured to be accepted by the cellular network hosted access control mode; in step 2204, the processor of the access control server sends, based on the affirmative access permission indication and through the application, at least one access program instruction to the computing device to unlock the access-restricted digital resource for access through the computing device.

[0685] [ Figure 23 ]

[0686] Figure 23 An illustrative, non-limiting example is described that is based at least in part on mobile communication signals and at least in part on at least some embodiments of the present disclosure. In some embodiments, Figure 23 An exemplary process may include at least the following steps: in step 2301, a processor of an access control server sends at least one application instruction to a cellular device via an application and a communication network to display a door 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 architecture and operatively linked to an access-restricted digital resource, restricted from access via the cellular device; in step 2302, the processor of the access control server receives an access request based on at least one activity associated with the access controller interface element from the cellular device; wherein the access request includes data including: an access code and a cellular identity linked to the cellular device; in step 2303, the access control server receives an access control schema hosted by the cellular network, in response to receiving, processing and accepting a series of mobile address-derived signals (at least a portion of the data), as disclosed herein, a positive access permission indication from the cellular device associated with the cellular identity; in step 2304, the processor of the access control server sends, based on the positive access permission indication and via the application, at least one access program instruction to the cellular device to unlock the access-restricted digital resource for access via the cellular device.

[0687] [ Figure 24 ]

[0688] Figure 24 An illustrative, non-limiting example is described that is based, at least in part, on mobile communication signals consistent with at least some embodiments of the present disclosure. In some embodiments, Figure 24 An exemplary process may include at least the following steps: in step 2401, recording an expected data record as an access control mechanism for accessing a digital resource with restricted access through an access control platform, the expected data record including: an access code and an identity linked to a computing device; the access code is associated with the access-restricted digital resource, restricting access through the computing device; the expected data record has been generated when an access controller interface element is displayed on a screen of the computing device; wherein the access controller interface element is operationally linked to the access-restricted digital resource; in step 2402, receiving, while displaying the access controller interface element, a mobile-originated communication including: the access code and the identity; in step 2403, performing confirmation of the expected data record of the communication with the mobile source through the access control platform; in step 2404, when the confirmation is successful: instructing, through the access control platform, based on at least a portion of the data, a cellular communication network to perform at least one action on an access control mode hosted by the cellular network to generate a session record associated with the identity; and, in step 2405, authorizing, through the access control platform, the computing device for unlocking the access-restricted digital resource for access through the computing device.

[0689] [ Figure 25 ]

[0690] Figure 25 An illustrative, non-limiting example is described that is based at least in part on mobile communication signals consistent with at least some embodiments of the present disclosure. In some embodiments, Figure 25An exemplary process 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 access-restricted digital resources, the expected data record including: an access code and an identity linked to a computing device; the access code is associated with the access-restricted digital resource, restricting access through the computing device; when an access controller interface element is displayed on a screen of the computing device, the expected data record has been generated; wherein the access controller interface element is operationally linked to the access-restricted digital resource; in step 2502, receiving, by the access control platform, and simultaneously displaying the access controller interface element, a mobile source communication including: the access code and the identity; in step 2503, performing, by the access control platform, confirmation of the expected data record of the communication with the mobile source; in step 2504, when the confirmation is successful: by the access control platform, based on at least a portion of the data, instructing a cellular communication network to perform at least one action with an access control mode hosted by the cellular network to generate a session record associated with the identity; and, in step 2505, authorizing, by the access control platform, the computing device for unlocking the access-restricted digital resource for access through the computing device.

[0691] Illustrative, non-limiting embodiments of access control network architectures, systems, components and / or elements programmed with intended keys and machine learning techniques to access restricted resources / services and identify, sequence, modify and / or control autonomous programmable entities (e.g., robots / bots) and their visual patterns, and methods of using the same

[0692] This article will discuss some illustrative, non-limiting technical issues

[0693] One technical problem addressed in this disclosure is that the security of traditional and analog username and password (UNAP)-based systems can be severely compromised because many users choose convenience over security, select easier-to-remember passwords over stronger, more obscure ones, and / or reuse the same passwords across multiple services. For example, large-scale data security breaches and privacy issues have undermined online trust, and increased risk and exposure have further weakened UNAP methods of accessing services. Users may also be increasingly reluctant to disclose personal data to online entities in general.

[0694] Another technical issue addressed in the present disclosure is that users may enter their identities via a keyboard or keypad, which can be a fundamental vulnerability because, for example, keystrokes are typically not encrypted when pressed (entered) and can be intercepted by, for example, keyloggers and / or remote control software. Therefore, regardless of the security of Internet communication protocols, data manually entered into a device using a keyboard or keypad can be captured by malicious actors in plain text or equivalent and related text codes (e.g., ASCII).

[0695] However, another technical problem addressed in the present disclosure is that usernames and passwords may often be required to be stored by third-party service providers, who may often fail to take necessary data protection precautions. Many large-scale data breaches and leaks have exposed and rendered the online identities of millions of people vulnerable to attack.

[0696] However, another technical issue addressed in this disclosure is that malicious actors such as scammers and phishers may exploit computer-driven social engineering techniques to extract login credentials from unsuspecting users with alarming frequency.

[0697] However, another technical issue addressed by the present disclosure is that, with the advent of smartphones and app stores, countless application providers have gained access to computer data stores that contain deeply personal data, device controls, and functionality, such as, but not limited to, contacts, phone events, screen recordings, cameras, and / or keyboards. For example, users may habitually and unnoticedly grant software-requested access to third-party applications and / or application functionality that may exceed the scope of the services provided. As a result, modern digital cellular phones are considered by at least some to be a security Pandora's box.

[0698] However, another technical problem to be solved in the present disclosure is that, given that many Internet services use MSISDNs to provide two-factor authentication (2FA) communications, it is not possible to securely authenticate users using their mobile phone numbers. For example, in a typical 2FA procedure, the Internet service's computing equipment may send a one-time password (OTP) to a registered mobile device using the MSISDN via SMS and / or phone call, requesting the user to re-enter the code into the intended Internet authentication session.

[0699] However, another technical problem to be addressed in the present disclosure is that, given that many services intentionally provide APIs to automate core components of their own service offerings, there may be no known method to effectively detect BOTS (computer programs configured / programmed to perform automated repetitive tasks) running on a large scale on the service platform. For example, but not limited to, automatically replying to messages, scheduling message replies, selectively replying to messages by topic and / or keyword, automatically following other users, creating user lists, discovering market trends, automatically reacting to trends, conducting research, conducting online polls, disseminating news, etc.

[0700] Online social media platforms (e.g. Meta TM / Facebook TM / WhatsApp TM(Meta Platforms, Inc., CA), Twitter TM (Twitter, Inc., CA, etc.) may lack an automated method for, for example, but not limited to, detecting, highlighting, and / or flagging automated computer processes (e.g., "bots" or robots) that may register and masquerade as humans. For example, while bots can provide valuable automated services, they can not only artificially inflate the number of registered users, but may also disseminate false and / or misleading information to influence public opinion and / or exploit computer technology for malicious purposes, such as, but not limited to, undermining free speech and democratic processes.

[0701] For example, it is technically necessary to clearly distinguish between real beings (humans) and their inputs and those created by artificial entities (i.e., automatons, bots), which may be malicious in content and / or intent. This separation is crucial to restoring balance online, at least in part because of the classic dilemma of protecting free speech in digital ecosystems: allowing free speech versus ensuring that truth, based on data-backed facts, prevails. This balance is essentially a numbers game. For example, because bots are often artificially generated and programmatically injected into online systems, their number can far outnumber the number of people who manually register to participate online. This statistic alone creates an epically uneven playing field, statistically and tangibly distorting not only the source of data but also its reliability and the ability to arbitrarily influence online public opinion—for example, by increasing or decreasing the prominence of posts (tweets), posing an existential threat to democratic, free, and fair processes (e.g., elections).

[0702] For example, online forums may allow people (and BOTS) to post, so it is often impossible to accurately determine the percentage of the online base that may be BOTS, which can have a negative domino effect on, for example, but not limited to, digital advertising. In particular, advertising that is sold based on digital views (also known as "brand" or "mind share" advertising) rather than necessarily based on conversion rates (click-through rates and product purchases) because if at least a portion of the ads are unknowingly served to BOTS, they cannot be counted as "viewed" (by potential customers), but they are currently being billed as such.

[0703] However, another technical issue being addressed in the present disclosure is that some 2FA processes / systems may allow malicious actors to access phone-based messaging (e.g., SMS) and / or phone functionality to intercept 2FA codes and automatically control a user's cellular-enabled computing device to return the 2FA code via IAPP to complete the authentication cycle, without the user's intervention and / or the user's understanding of the consequences of their actions in facilitating the malicious actor.

[0704] However, another technical problem addressed in the present disclosure is that the conventional SS7 signaling network typically used to transmit these 2FA codes and calls may have numerous vulnerabilities that allow a malicious actor with access to an SS7 peering point to redirect and / or intercept such mobile terminated events, thereby compromising these authorization codes and / or signals. For example, at least some of the vulnerabilities may be due to, for example, but not limited to, the fact that the source of SS7 messages may not be authenticated, and thus critical network control messages may be injected into the SS7 network from one or more entities masquerading as mobile phones and / or switching elements. Thus, for example, a malicious actor could inject and thereby forge mobile phone location updates (or similarly overwrite subscriber information in an HLR, etc.), hijacking cellular routing to surreptitiously intercept calls and / or texts.

[0705] However, another technical issue being addressed in this disclosure is that some authenticator apps may be programmed to push notifications to registered cellular devices over a data connection, prompting the user for confirmation before granting access to an online resource (e.g., a service).

[0706] However, another technical issue being addressed in the present disclosure is that while claiming to overcome at least one or more of the identified 2FA issues, at least some authenticator applications may cause attention deficit disorder (ADD), poor muscle memory and / or hand-eye coordination, which may cause users to habitually and / or inadvertently grant access rights. For example, ADD may manifest as a form of bipolar disorder, which may cause a user with ADD to press / select a "green" button or a button labeled "YES" when they intended to press a "red" colored button or a button labeled "NO."

[0707] However, another technical problem being addressed in the present disclosure is that a potentially large number (e.g., potentially billions) of cellular users may still only use so-called "basic feature" phones, which typically lack so-called "advanced" data push notification services (e.g., web push notifications, rich push notifications with images, emojis, etc.), and they are unable to take advantage of such "high-end" authentication protocols, for example.

[0708] However, another technical problem addressed by the present disclosure is that while certain user interactions preclude automation via programmed instructions, there exists a phenomenon known as "click farming," which utilizes, for example, hundreds or thousands of programmed mobile phones and / or low-skilled and / or low-wage human resources (primarily in developing countries) to perform automated (mobile phones programmed to activate user interface elements) (bot phones) and / or manual clicks (e.g., manually activating user interface elements) on behalf of actors with malicious intent to circumvent certain authentication processes. For example, human click farms or hybrid click farms, having bot phones with some human input, can be used to effectively bypass CAPTCHA-type systems that may present visual recognition tasks and / or difficult problems to solve designed to distinguish between human and machine input. Furthermore, so-called "click farming" typically places a considerable strain on computing resources and / or network traffic, thereby reducing the availability of both for other uses.

[0709] Some illustrative, non-limiting technical solutions described herein

[0710] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein, such as providing security enhancement methods, access control network architectures, and systems for identifying and authenticating users in various environments, such as online and offline. For example, at least some embodiments of the present disclosure can leverage secure mobile native signaling capabilities on digital networks for cellular-based authentication, which will provide trusted, seamless, and frictionless user identity authentication for access to digital products and services at scale.

[0711] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein, such as, but not limited to, securely providing identification outside the Internet domain / band by shifting the dependency, and the resulting vulnerability, from the user, identification itself to a trusted intelligent network (IN), such as, but not limited to, a cellular network, without any user intervention and therefore without any additional external intrusion points (e.g., from malicious actors outside the IN / cellular network).

[0712] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein, such as, but not limited to, programming an Internet Application (IAPP) to connect to an exemplary disclosed so-called "STARKEY" platform (also interchangeably referred to herein as the "STARKEY" platform) through an application programming interface (API), for example, but not limited to, an access control platform), requesting and then presenting a challenge to a user, which challenge may include, but is not limited to, a randomly generated series (sequence) of numbers (e.g., a sequence of numbers, a randomly generated sequence of alphanumeric characters, etc., which may also be referred to herein as an expected access control digital key). In some embodiments, the randomly generated series of numbers (the expected access control digital key) may be prefixed with one or more predetermined or randomly selected symbols (e.g., a star symbol (*), a symbol routing prefix) before being presented to the user, collectively forming a "STAR Challenge," "STAR Random Challenge," "STAR Random Phone Number," "Star Random Challenge and Response," or "Star Challenge" as referred to herein. In at least some embodiments, the exemplary STARKEY platform (access control platform) can be programmed to generate / form a StarChallenge. In at least some embodiments, another computing device (e.g., a user computing device, a provider computing device, as described herein) can be programmed to generate / form a Star Challenge before presenting it to a user by adding one or more predetermined symbols to a randomly generated sequence of numbers (the intended access control digital key). In at least some embodiments, the Star Challenge and the intended access control digital key are configured to be recognizable to the user as a series of phone numbers and symbols that the user can select and / or enter on a telephone keypad. For example, both the Star Challenge and the intended access control digital key can be structured to have a sufficiently random number of numbers so that a malicious actor would need to try millions, billions, trillions, or even quadrillions of permutations, thereby making a brute force attack potentially unlikely and impossible due to their cellular origin and sufficiently short lifespan, as disclosed herein.

[0713] As described herein, but not limited to, by way of illustration only, billions of users / people own personal mobile phones, and each mobile phone has a unique digital user identity, such as, for example, an MSISDN (Mobile Subscriber Integrated Services Digital Network, also known as a Mobile Station International Subscriber Directory Number). Each MSISDN is a directory telephone number that users dial to establish contact with one another. As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that address one or more of the technical problems identified herein, such as, but not limited to, leveraging each cellular phone number as a ubiquitous / unique personal digital identity (UPDI). For example, but not limited to, registering a user online using their mobile phone number may provide a globally unique identity (GUID) that can seamlessly work with contact lists (e.g., personal phone directories), thereby enabling viral spread between IAPP links and social directory connections. In some embodiments, the GUID can 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 identities (e.g., user identities, computing device identities, etc.). For example, but not limited to, an OTT phone and / or messaging application may include presence-based directories, video chat, multi-party conferencing, screen sharing, and / or PSTN calling. For example, but not limited to, an OTT phone and / or messaging application may be a "fat" client, a browser-based "thin" client, and / or a WebRTC (Web Real-Time Communications)-based "thin" client.

[0714] For example, when cellular user A uses a cellular-capable computing device (e.g., a cellular phone / smartphone) with MSISDN-A and registers with an Internet application (IAPP), using its MSISDN-A as an identity (an entry in the modified phone address book), IAPP and / or other related programs / applications / networks can determine that for a communication sent by another user of IAPP to user A (MSISDN-A), the recipient cellular device MSISDN-A is already registered and connected to IAPP, and therefore the communication can be routed OTT using an internet connection (e.g., an Internet network) instead of routing the communication through the cellular network.

[0715] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein, such as registering users through the identities described herein (e.g., MSISDN) to promote the spread and adoption of IAPP services, as any contacts registered with IAPP (e.g., social media applications / websites) may be noted in a suitably modified phone address book program, and any contacts that have not yet registered may be invited to join the IAPP community on their MSDISN, with onboarding mediated by a network (e.g., IN, cellular network) relying on the modified phone address book program.

[0716] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein, such as, but not limited to, recording a series of randomly generated numbers (e.g., an expected access control digital key), or a series of randomly generated numbers with symbols (e.g., a STAR Challenge), or any other similar suitable data, as a desired record in non-transitory memory; whereby an access control platform can be programmed to wait to receive a series of network (e.g., IN or cellular network) mediated signals from an unknown cellular device that will exactly match the desired record, number by number. In some embodiments, once a user satisfies such stored expectation, for example, by dialing a series of random digits displayed in the form of a STAR Challenge on a cellular device as a telephone number, and the cellular network routes such a "STAR" call request to the serving STARKEY platform (access control platform), the cellular device transmits a matching STAR address signal (the STAR Challenge recorded in the expectation), also referred to herein as a "STAR Challenge Response", which can be securely identified by extracting 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.

[0717] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more technical problems identified herein, such as, but not limited to, programming an IAPP to present a series of randomly generated 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, but not limited to, a STAR Challenge element (e.g., a button with a STAR Challenge text label that displays the STAR Challenge random number series as a click-to-call button / link)). In some embodiments, the illustrative STAR Challenge element can be programmed to be displayed in the form of a phone button (e.g., a green button with an icon / image of a phone or phone receiver), displaying the STAR Challenge, including a series of randomly generated numbers (e.g., an expected access control digital key) that a user will activate to dial (the STAR Challenge phone number), and / or a phone QR code encoded with the STAR Challenge (the STAR Challenge phone number), allowing the user to scan rather than manually enter the STAR Challenge or a series of numbers randomly generated therefrom when using the IAPP, such as, but not limited to, on a desktop / laptop computer or in a virtual reality (VR) headset that does not have native phone dialing capabilities. In some embodiments, but not limited to, upon activating (e.g., but not limited to, "clicking") the STAR Challenge button or scanning a QR code encapsulating a STAR Challenge phone number, the cell phone dialer may then present the auto-populated / entered random phone number as the dialing address to complete the STAR Challenge response.

[0718] As detailed herein, at least some embodiments of the present disclosure are directed to one or more technical solutions that are intended to address one or more of the technical problems identified herein, such as, but not limited to, providing that when a user dials a number containing a series of random digits (an expected access control digital key) or a number containing a series of random digits prefixed with a symbolic routing prefix (e.g., a STAR Challenge random phone number), thereby generating a StarChallenge response, by pressing a GUI element (e.g., a button shaped as and / or displaying a green phone icon, but not limited to), the user's associated cellular device or the user's associated cellular service computing device (e.g., a tablet) will emit a phone-type address signal (e.g., a STAR Challenge random phone number). Challenge address signal), for example, but not limited to, transmitted over the air to the cellular network, which will then perform an authentication, authorization, and ac...

Claims

1. A method for access control, comprising: displaying, by at least one processor of at least one entity computing device associated with the entity, a payment interface element in a graphical user interface of a user computing device associated with the user, the payment interface element for paying for access to the at least one access-restricted resource; wherein at least one physical computing device is operable to interact with the access control platform; Among them, the payment interface elements include cellular billing payment method and purchase price; In response to detecting that a user selects a cellular billing payment method, the access control platform, via at least one processor of at least one entity computing device, instructs the access control platform to generate a desired data record as an access control mechanism for accessing restricted resources before paying a purchase price, the desired data record comprising: Access code and an identity associated with the user's computing device; At least one processor of at least one entity computing device receives an access authorization indication from an access control platform, where the access authorization indication indicates at least the following: i) The access control platform receives a mobile-originating communication, wherein the mobile-originating communication has data including: Specific access code and specific identity, ii) a specific access code that matches the access code, iii) a specific identity that matches the identity linked to the computing device used, and iv) payment of the purchase price has been successfully processed or has been declined based on, Cellular Network Hosted Access Control Model and a mobile phone account associated with an identity connected to the user's computing device; and At least one processor of at least one entity computing device performs at least one of the following operations in response to the access authorization indication: Unlock at least one restricted resource for the user to access, or Instructing the user computing device, at least one other computing device that controls the access-restricted resource, or both, to unlock at least one access-restricted resource for access by the user.

2. The method according to claim 1, wherein The at least one access-restricted resource is at least one product, at least one service, or a combination of at least one product and at least one service.

3. The method according to claim 2, wherein: At least one of the products is digital content.

4. The method according to claim 2, in, at least one product is at least one physical product; wherein at least one physical computing device is a physical vending machine; and Wherein unlocking the at least one access-restricted resource results in providing the at least one physical product to the user.

5. The method according to claim 2, in, at least one product is at least one physical product; wherein at least one other computing device is a physical vending machine; and Wherein, instructing to unlock the at least one access-restricted resource for access by the user results in providing the at least one physical product to the user.

6. The method according to claim 1, in, When payment of the purchase price is successfully processed, the prepaid cellular account is debited in the amount of the purchase price in accordance with the cellular network managed access control model.

7. The method according to claim 1, wherein The mobile phone account is a prepaid mobile phone account; as well as Wherein, when the access authorization indication further indicates that payment of the purchase price has been refused, the method further includes: A notice is displayed, via at least one processor of at least one entity computing device, on a graphical user interface of a user computing device to indicate that cellular credit associated with the user is insufficient.

8. The method according to claim 1, wherein The access authorization indication also indicates that the access control platform has not received a mobile originated communication within a predetermined period of time.

9. The method according to claim 1, wherein The identity is: Mobile ID or Derived from mobile phone identity; and Among them, mobile phone identity: A cellular device that is programmably associated with a computing device, or a computing device that supports cellular service.

10. The method according to claim 1, wherein The specific access code includes a symbol prefix.

11. A system for access control, comprising: at least one processor of at least one entity computing device associated with the entity; A non-transitory computer-readable medium storing software instructions that, when executed by at least one processor, instruct at least one physical computing device to: displaying a payment interface element in a graphical user interface of a user computing device associated with the user, the payment interface element for paying for access to the at least one access-restricted resource; wherein at least one physical computing device is operable to interact with the access control platform; Among them, the payment interface elements include cellular billing payment method and purchase price; In response to detecting that the user selects a cellular billing payment method, instructing the access control platform to generate a desired data record as an access control mechanism for accessing restricted resources before paying a purchase price, the desired data record including: Access code and an identity associated with the user's computing device; Receive an access authorization indication from the access control platform indicating at least the following: i) The access control platform receives a mobile-originating communication, wherein the mobile-originating communication has data including: Specific access code and specific identity, ii) a specific access code that matches the access code, iii) a specific identity that matches the identity linked to the computing device used, and iv) payment of the purchase price has been successfully processed or has been declined based on, Cellular Network Hosted Access Control Model and a mobile phone account associated with an identity connected to the user's computing device; and In response to the access authorization indication, perform at least one of the following operations: Unlock at least one restricted resource for the user to access, or The user computing device, at least one other computing device that controls the access-restricted resource, or both are instructed to unlock the at least one access-restricted resource for access by the user.

12. The system according to claim 11, wherein The at least one access-restricted resource is at least one product, at least one service, or a combination of at least one product and at least one service.

13. The system according to claim 12, wherein: At least one product is digital content.

14. The system according to claim 12, in, at least one product is at least one physical product; wherein at least one physical computing device is a physical vending machine; and Wherein unlocking the at least one access-restricted resource results in providing the at least one physical product to the user.

15. The system according to claim 12, in, at least one product is at least one physical product; wherein at least one other computing device is a physical vending machine; and Wherein, instructing to unlock the at least one access-restricted resource for access by the user results in providing the at least one physical product to the user.

16. The system according to claim 11, in, When payment of the purchase price is successfully processed, the prepaid cellular account is debited in the amount of the purchase price in accordance with the cellular network managed access control model.

17. The system according to claim 11, wherein: The mobile phone account is a prepaid mobile phone account; and in, When the access authorization indication further indicates that payment of the purchase price has been denied, the software instructions further instruct the at least one physical computing device to: Causing a notification to be displayed on a graphical user interface of a user computing device to indicate that cellular credit associated with the user is insufficient.

18. The system according to claim 11, wherein: The access authorization indication also indicates that the access control platform has not received a mobile originated communication within a predetermined period of time.

19. The system according to claim 11, wherein: Specific access codes include a symbol prefix.

20. The system of claim 11, wherein: The identity is: Mobile ID or Derived from mobile phone identity; and Among them, mobile phone identity: A cellular device that is programmably associated with a computing device, or a computing device that supports cellular service.

Images