Cognitive hotspot provisioning and network prioritization

A computer implemented method and system are disclosed for dynamically enabling a first user device operated by a first user to provide wireless hotspot capability for a wireless hotspot session to a second user device operated by a second user. The wireless hotspot session is accepted based at least on urgency and bandwidth requirement of the second user device. When the first user device accepts a connection to the second user device to provision a wireless hotspot for the wireless hotspot session, the first user restricts use of the second user device in the wireless hotspot session, based on bandwidth and context of use of the second user device. The first user device may refuse a connection by rejecting the wireless hotspot session request. wireless hotspot session transactions information is provided as blockchain ledgers.

BACKGROUND

Aspects of the present invention relate generally to peer sharing of Wi-Fi hotspots and, more particularly, to selective utilization of network bandwidth based on selection of applications in use and urgency of a secondary user, in accordance with the rules configured by a primary user providing the service.

Wi-Fi and broadband data plans are commonplace among users of mobile devices (i.e., mobile phones, tablets, laptops, etc.). Some mobile devices have access to broadband networks, such as satellite and cellular networks. Some mobile devices can connect to the Internet only via a Wi-Fi connection, such as through an 802.11 protocol transceiver, without broadband access. Many cellular carriers allow a user to use their mobile phone as mobile hotspot. As a mobile hotspot, a user is connected to broadband service via their cellular transceiver in the mobile phone, and then allow another device to access the broadband network by connecting to the phone's Wi-Fi transceiver. This type of sharing requires the second device to be logged in with the phone's mobile hotspot password.

SUMMARY

In a first aspect of the invention, there is a computer-implemented method including: receiving by a first user device operated by a first user, a request for a wireless hotspot session by a second user device operated by a second user, the request including a level of urgency and bandwidth requirement of the second user device; determining by the first user device whether to authorize the requested wireless hotspot session based in part on the level of urgency and the bandwidth requirement of the second user device; responsive to authorization by the first user device, connecting by the first user device, the second user device to the first user device's wireless hotspot for the wireless hotspot session, and restricting use of the second user device in the wireless hotspot session, based on the bandwidth requirement of the second user device and context of use of the second user device; responsive to rejection by the first user device, the first user device refusing a connection to the second user device by the first user device for the wireless hotspot session; and providing by the first user device, transaction information corresponding to the wireless hotspot session as a blockchain ledger.

In another aspect of the invention, there is a computer program product including one or more computer readable storage media having program instructions collectively stored on the one or more computer readable storage media. The program instructions are executable to: identify a criticality level for bandwidth required by a second user of a second user device; identify by the second user device, at least one device having hotspot bandwidth in proximity to the second use device; assign a trust score to each of the at least one device based on a known transaction history of each of the at least one device or transaction history broadcast by the at least one device; compute a reachability score for each of the at least one device; select a first user device from the at least one user device based in part by the trust score and reachability score corresponding to the first device; and send a request for a wireless hotspot session to the first user device, the request including the and identification of the second user device and the identified criticality level for bandwidth required by the second user device. In response to the first user device accepting the wireless hotspot session and connecting to the second user device, the second user device provides a transaction blockchain ledger for the wireless hotspot session.

In another aspect of the invention, there is system including a processor, a computer readable memory, one or more computer readable storage media, and program instructions collectively stored on the one or more computer readable storage media. The program instructions are executable to dynamically enable a first user device operated by a first user to provide Wi-Fi hotspot capability for a wireless hotspot session to a second user device operated by a second user, based at least on urgency and bandwidth requirement of the second user device; responsive to authorization by the first user device, connect the second user device to the first user device's Wi-Fi hotspot for the wireless hotspot session, and restrict use of the second user device in the wireless hotspot session, based on bandwidth and context of use of the second user device; responsive to rejection by the first user device, refuse a connection to the second user device by the first user device for the wireless hotspot session; and provide transaction information corresponding to the wireless hotspot session as a blockchain ledger.

DETAILED DESCRIPTION

Aspects of the present invention relate generally to peer sharing of wireless hotspots and, more particularly, to selective utilization of network bandwidth based on selection of applications in use and urgency of a secondary user, in accordance with the rules configured by a primary user providing the service. According to aspects of the invention a primary user allows a secondary user to use broadband connectivity via a selective Wi-Fi connection. In embodiments, secondary users are allowed access to the primary user's broadband connection based on several contextual and historical factors. For instance, in some embodiments, the secondary user's historical use of the sharing network, the type of application they need to use, and the urgency of their need to connect to the Internet may be weighed by the primary user to determine whether to grant the secondary user access to their bandwidth. In an embodiment, some friends and family of the primary user may be granted automatic access, or priority access. In this manner, implementations of the invention may allow users of the sharing network to borrow a broadband connection from another without requiring the necessity of face-to-face interaction explaining to the donor why the loan is necessary and asking for a password. This sharing system acts on a case-by-case basis based on necessity and the primary user's available network bandwidth. Previous methods of giving out your password, even if thought to be temporary, can allow the secondary user to connect to the primary user's network connection whenever their mobile hotspot is turned on, because mobile hotspot and Wi-Fi passwords are often changed infrequently and stored in the device once connected. Embodiments may use blockchain protocols to ensure that both bandwidth donors and borrowers are trustworthy based on their past activities/transactions. In some embodiments, incentives may be provided to donors to encourage them to continue offering unused bandwidth.

One embodiment is a computer-implemented method comprising: dynamically enabling a first user device to provide wireless hotspot capability to a second user device based on urgency, e.g., need for the second user device to access the wireless network, and bandwidth requirement; connecting the second user device to the first user device's mobile hotspot; restricting use of the second user device connected to the mobile hotspot of the first user based on bandwidth and context of use of the second user device to avoid misuse of the first user device's mobile hotspot. An embodiment includes creating a list of trusted network devices for at least the second user device to connect to. An embodiment includes enabling a first user device to “donate” access to a second user device for a specific context. An embodiment includes assigning a higher priority for a user device of a plurality of user devices based on need. An embodiment includes leveraging a blockchain network to keep track of transactions comprising connection to devices and devices providing wireless hotspot capabilities.

Implementations of various embodiments provide an improvement in the technical field of mobile Wi-Fi and wireless hotspots. In particular, implementations automatically identify trusted donors and benefactors of mobile network bandwidth and provide either automatic connection or managed connection based in part on urgency, needed resources and context of the borrower requests. Implementations utilize a blockchain network to store historic signed transaction ledgers for use by the donors and borrowers. The donor's system retrieves historical transaction data from the blockchain network after receiving a borrow request. The system either presents the donor with a connection recommendation, or automatically rejects or accepts the request based on the context and historical data. In an embodiment, the user may override the recommendation to approve or reject the connection, and manually set constraint restrictions for the session. Connection request transaction data is stored in the blockchain in open signed ledgers for later use. This improves network access to borrowers who might not have access to a network connection otherwise. Use of the blockchain helps ensure that only trusted users have access to the system. In particular, implementations are usable to modify the blockchain ledgers and enable communication of a borrower to the Internet or other communication network via a borrowed pass-through network connection provided by a donor.

It should be understood that, to the extent implementations of the invention collect, store, or employ personal information provided by, or obtained from, individuals (for example, usernames, location, device identifications, applications used, etc.), such information shall be used in accordance with all applicable laws concerning protection of personal information. Additionally, the collection, storage, and use of such information may be subject to consent of the individual to such activity, for example, through “opt-in” or “opt-out” processes as may be appropriate for the situation and type of information. Storage and use of personal information may be in an appropriately secure manner reflective of the type of information, for example, through various encryption and anonymization techniques for particularly sensitive information.

Implementations of the invention may include a computer system/server12ofFIG.1in which one or more of the program modules42are configured to perform (or cause the computer system/server12to perform) one of more functions of the mobile hotspot provisioning96ofFIG.3. For example, the one or more of the program modules42may be configured to support a primary user providing Wi-Fi bandwidth to a secondary user by processing an incoming request for hotspot sharing including evaluating a trusted tier score for incoming request; creating allowance constraints based on timer, bandwidth, relationship graph and application usage; and accepting incoming requests with restrictions imposed by created allowance constraints.

Implementations of the invention may include a computer system/server12ofFIG.1in which one or more of the program modules42are configured to perform (or cause the computer system/server12to perform) one of more functions of the mobile hotspot provisioning96ofFIG.3to support a secondary user. For example, the one or more of the program modules42may be configured support a secondary user requesting Wi-Fi bandwidth by establishing a trusted connection to the primary user; requesting use of the primary user's broadband connection as a Wi-Fi hotspot; providing context information related to the request; and when authorized, connecting to a network such as the Internet using the primary user's bandwidth. In implementations, the computer system12is configured to act as a primary user and as a secondary user based on the user's needs.

FIG.4shows a block diagram of an exemplary environment in accordance with aspects of embodiments. In embodiments, the environment includes a wireless communication network410accessible by multiple users, each operating a mobile device411-415. Although only five mobile devices are shown for illustrative purposes, it will be understood that more or fewer mobile devices may be present in the network. Mobile devices411-415include, but are not limited to, mobile phones, electronic personal assistants, laptops/notebooks, tablets, and other mobile Internet devices. The wireless communication network410may be accessible by cellular broadband connections via unlimited or limited metered access for service subscribers, roaming access to non-subscribers, and generally for either a pre-paid monthly fee or fee for actual use. A mobile device needs to be configured with appropriate protocols for the communication service. For instance, cellular networks in the United States are typically either CDMA (Code Division Multiple Access) or GSM (Global System for Mobiles) networks. Differences between the two networks includes the frequency bands they run on and the way they transmit voice data across these bands. A mobile device can only directly connect to the type of network for which is it was originally designed. However, most mobile devices are Wi-Fi enabled for connection to the Internet using a wireless connection according to the IEEE 802.11 standard protocol. Embodiments as described herein enable a user (e.g., a secondary user), with a Wi-Fi connection but limited or no broadband connection, i.e., GSM or CDMA, to access the Internet via the broadband or other network connection of another user (e.g., a primary user). This is especially useful when the secondary user needs quick access to the Internet, but has no data minutes left, or is using a different protocol or service when traveling outside of their home area.

In an embodiment, a mobile device411-415may be configured to act as both a primary user (e.g., a lender or donor of broadband access), and a secondary user (e.g., a donee or borrower of broadband access). The mobile device411-415acts as either the primary or secondary user at any given time, but not both at the same time. A request430from a secondary user414to primary user411, for example, for borrowed broadband, initiates a trusted connection440between the two devices. The primary user device411evaluates call context and assigns a criticality level to the secondary user device request430. In an embodiment, the criticality level has three levels, such as C1, C2, and C3. Other embodiments may use more or fewer than three levels. In an embodiment, the secondary user device request for bandwidth includes a self-identified criticality level. The secondary user device414may iterate over various donor hotspots (i.e., user devices411-413) to assess reachability and viability of multiple primary users' broadband access within the wireless communication network410. A trusted tier score is assigned to each donor/donee pair. To evaluate the trust level of a borrower, the donor device reviews previous borrowing and lending history of the current borrower, for instance using blockchain ledgers for transaction history. The borrower may also evaluate the potential donor's history, when available.

In an embodiment, blockchain technology420is used to store historical ledgers corresponding to users' lending and borrowing transactions. Each user device411-415has a private key used to lock their transactions from manipulation in the blockchain. The historical ledgers remain visible to users of the hotspot provisioning system but cannot be altered without the private key.

The borrower device414computes an overall reachability score for the potential donor(s)411-413and sends a request430to the donor411with the highest reachability score. In an embodiment, the borrower device414may send requests to multiple potential donors to increase the odds that one donor will allow the broadband access loan, e.g., a wireless hotspot session. The request may include the trusted tier score as calculated by the borrower device.

When a donor receives a request to lend broadband access, the donor device evaluates the trusted tier score for the incoming request. The donor device creates allowance constraints based on timer, bandwidth, relationship graph and applications usage. The donor may accept the incoming request with restrictions imposed by created allowance constraints.

The borrower connects to the donor's hotspot440to commence their temporary use of the broadband connection within the allowance constraints. Constraints may include on-line time, data used, and the application connecting to the network. When the borrower concludes their use of the hotspot, the donor device and borrower device store their transaction ledgers to the blockchain420. In an embodiment, a user's records are stored in one ledger that is updated each time a hotspot provisioning transaction is accepted and completed. In an embodiment, the ledger may include on-going hotspot provisioning transactions which are updated when the transaction is complete. Transaction ledgers are digitally signed by the user devices, but left open unencrypted, for access by other users assessing trust levels. In an embodiment, the ledgers for a single hotspot transaction are provided by both the donor and borrower and are ensured to match by the blockchain service.

FIG.5shows a block diagram of an exemplary mobile hotspot provisioning environment500, in accordance with aspects of the invention. In an exemplary embodiment, primary user device510acts as a donor in a current transaction. Secondary user devices511and513act as borrower devices in the current transaction. Primary user device510is connected to a communication network via a broadband connection. Primary user device also has Wi-Fi521enabled with a level of security523, and at a strength level527. In an example, primary user device510is connected to the network via a VPN (virtual private network) so the security level523is high. As an alternative, primary user device may be connected to the network with a wired connection525and provide network access via the wired connection rather than broadband cellular. Secondary user devices511and513are within a proximity of primary user device510and may desire to borrow broadband access to connect to the communication network (i.e., the public Internet). Secondary user devices511,513can communicate with the primary user device510using Wi-Fi, Bluetooth, near field communication (NFC) or any wireless technology that enables peer to peer connection, now known or available in the future.

FIG.6is a block diagram showing an exemplary blockchain environment, in accordance with aspects of the present invention. A blockchain can be defined as a distributed ledger taking the form of an electronic database that is replicated (i.e., distributed) on numerous compute nodes spread across an organization, a country, multiple countries, or the entire world. Records in a blockchain are stored sequentially in time in the form of blocks. Each block in the chain has a blockheader which contains various source data, a timestamp, etc. A hash is allocated to each blockheader which uniquely identifies the source data. The blockheader includes a reference to the hash of the previous block in the chain. When later blocks are added, each will have a reference to the block that precedes it in the chain. In other words, the blockchain is a type of distributed ledger. Ledgers may be stored locally on user devices that use them, as well as distributed within the blockchain environment. Ledgers periodically synchronize with corresponding ledgers on distributed devices. In an embodiment, the mobile devices using the hotspot provisioning system may be considered to be blockchain nodes. Therefore, a local copy of ledgers is stored on the local device and synchronized with the distributed nodes periodically when connected to the network. In an embodiment, local ledgers may be limited to transaction data for the mobile device itself and devices that have been in proximity with the mobile device or previously involved in a transaction with the mobile device in order to save storage space on the device.

In an embodiment, the blockchain is distributed in the cloud environment600which may be the same cloud environment50as inFIG.2. Various nodes601-607may exist in the environment and communicate with one another to store/retrieve and synchronize blocks, or ledgers, in the chain. It will be understood that seven nodes601-607are shown for illustrative purpose, but that in implementation more or fewer nodes may be present in the cloud environment. This example shows ledgers621and623stored in nodes601and602, respectively. It will be understood that theses ledgers621and623will be duplicated and synchronized with other nodes in the cloud600, as necessary. In an embodiment, ledgers621and623comprise historical data corresponding to mobile hotspot provisioning transactions.

FIGS.7A-7Bshow flowcharts of an exemplary method for mobile hotspot provisioning, in accordance with aspects of the present invention. Operations of the method may be carried out in the environment ofFIGS.4-6and are described with reference to elements depicted inFIGS.5and6. In implementations, a user may generate goodwill with other users by frequently acting as a donor. Incentives may be provided to donors to motivate them to lend bandwidth, as discussed more fully corresponding toFIG.8. The donors' transactions are stored as ledgers in the blockchain to gain trust with other users. Frequent donors may be more likely to be accepted as borrowers based on their previous altruistic donor transactions. Therefore, it will be understood that a user's device will typically have provisioning functionality for both lending and borrowing broadband access. The lending and borrowing operations themselves may be separate program modules on the device or be integrated into one overarching program module. Program modules for lenders and borrowers may be implemented as program modules42of computer system/server12, as shown inFIG.1.

FIGS.7A-7Bare discussed herein with an example scenario for illustrative purposes. It will be understood that the lending and borrowing provisioning operations may differ in varying situations. In an example, John travels to the U.S. from India for training. John planned to purchase a mobile data plan at his destination, but circumstances prevented him from purchasing a local data plan. During weekend personal travel, when John does not have access to his office Wi-Fi, he desires to hire a shared ride to go sightseeing. At his hotel, he has Wi-Fi access and is able to book the automobile trip to the aquarium. However, John does not have access to Wi-Fi to book the return trip. Luckily, John will not be stranded because he subscribes to a mobile hotspot provisioning service, as described herein.

Referring toFIG.7A, John initiates a search for a wireless donor on his mobile phone (secondary user device) with the borrower operation module. John enters the context of his need into the borrower operation module. i.e., need to schedule a shared ride to avoid being stranded. The secondary user device evaluates the call context in block701and assigns a criticality level. In this case, the criticality level may be assessed as a C3 (highly important) due to the risk of being stranded. Criticality level is calculated in the secondary user device, but it gets evaluated in the primary user device (donor device) as part of the decision process as to accept/reject the incoming request, as discussed below. In an example, the primary user device configures the acceptable deviations from the baseline criticality or priorities scores. The same applies to the trust tier score.

The secondary user device iterates over possible donor hotspots within the vicinity and assigns them a trusted tier score, in block702. For purposes of illustration, the terms “in the vicinity” or “in proximity” are used to describe an area in which user devices can interact using a wireless network such as Wi-Fi, NFC, Bluetooth, or other wireless protocol. For instance, when a user device is “in proximity” to another user device, the two devices can see each other's presence and wireless signals. When in proximity, a user device's signal strength may vary, but is a non-zero strength. Possible donors in proximity to the secondary user device may broadcast information to be used in the evaluation of their trust tier. At this point, the secondary user device is not connected to the Internet and cannot access the full blockchain directly to determine trustworthiness. Some trust tier information may be stored locally as a circle of trust database, or as local ledgers. In an embodiment, a circle of trust is a list, database, or other data structure of users, each associated with a level of trust corresponding to the current user. The donors may broadcast some identifying information to enable the secondary user device to assign a trusted tier score to the donor device. In an example, a potential donor may be known to John as a friend, relative or colleague and automatically get a higher trust tier. Unknown donors will be assigned a trust tier based on a less trusting tier.

In embodiments, a service provider may offer to perform the processes described herein. In this case, the service provider can create, maintain, deploy, support, etc., the computer infrastructure that performs the process steps of the embodiments described herein for one or more customers. These customers may be, for example, any business that uses technology. In return, the service provider can receive payment from the customer(s) under a subscription and/or fee agreement and/or the service provider can receive payment from the sale of advertising content to one or more third parties. The secondary user device reviews history of John's borrowing and lending transactions which are stored as a local ledger, in block703. The secondary user device computes a reachability score for the potential donors, in block704. Reachability scores are based on at least, proximity to the donor; signal strength to the donor and if possible, the donor's signal strength to the broadband network; and trust tier of the donor. If there is more than one possible donor, the reachability scores may be ranked or prioritized. In an embodiment, the secondary user device sends a request for mobile hotspot provisioning to the highest ranked donor in block705. In another embodiment, a request is sent to more than one highly ranked donor to increase the chance that one will accept. In this case, the secondary user device will connect to the first donor to respond with an acceptance. Once the secondary user receives an acceptance and connects to the mobile hotspot, the user may commence to use the requested application.

In this example, once connected to the donor's mobile hotspot, John can operate his ride sharing application and schedule a ride back to his hotel. However, constraints on the accepted connection may preclude John from connecting to the Internet with other applications or for other purposes. Also, once connected to the Internet, John's mobile device will send transaction information to the blockchain for the current transaction to update the ledger associated with him and his device. In an embodiment, transaction ledgers are associated strictly with a user. In another embodiment, each user may have separate ledgers for each of their mobile devices.

FIG.7Bshows the method of operation on the primary user's device (donor's device), in accordance with aspects of the present invention. When a user has unused bandwidth, they can opt-in to be a donor by activating the donor program module of the mobile hotspot provisioning application on their mobile device. In some embodiments, this activation may be automatic when the device has excess bandwidth, based on pre-determined criteria. The user may configure the automatic activation criteria. This operation may cause a periodic broadcast of certain elements of the donor's profile, including information for a secondary user to assess a trust tier for unknown donors. In an alternative embodiment, the primary user device may wait until a query or request is broadcast by the secondary user device before transmitting any donor information. When the primary user device (donor device) receives a request for bandwidth in block720, the donor program module evaluates a trusted tier score for the secondary user and the request, in block721. Because the primary user device has access to the Internet, blockchain ledgers associated with the secondary user can be retrieved and factored into the trusted tier score. The request for bandwidth will include enough user information to identify the appropriate blockchain ledger(s). The request also includes information regarding which applications need access to the Internet, a criticality level for the request, and optionally an estimate of data required. In an embodiment, the estimate of data needed is automatically calculated by the secondary user device, based on historical use of the application(s) being requested for usage. In another embodiment, the secondary user manually inputs an estimate of data needed to be sent with the request.

If the request is acceptable to the primary user device, i.e., it will not use more bandwidth than the donor user is willing to donate or take more time than the donor user is willing to provide, and the trust tier is at an acceptable level, the primary user device may choose to accept the request for a temporary hotspot. In an embodiment, the choice to accept a request is made automatically by the primary user device. In another embodiment, the primary user device requires user intervention to approve or reject a request. If the request is not acceptable, the primary user device rejects or refuses the connection in block726and then may record this refused transaction in as a blockchain ledger in block725.

In an embodiment, the primary user device creates allowance constraints with restrictions for the wireless hotspot session, in block722. It will be understood that acceptance of the secondary user request for hotspot bandwidth creates a single session. Future requests by the same user will initiate subsequent session. Subsequent sessions require another evaluation. In an embodiment, close friends and family may be authorized automatically for a second or subsequent session when the primary user device has sufficient available resources. For instance, if the primary user device has a plan with unlimited data and the secondary user requests 500 MB of data use, then the primary user has sufficient data available. The primary user may define allowable use parameters for data and bandwidth. In another example, the primary user may have a 500 Mbps broadband connection and be expected to need 300 Mbps connection based on the application(s) in use. If the secondary user device needs 350 Mbps bandwidth then the primary user device does not have sufficient bandwidth to loan out. The primary user may set default limits allowable to loan out, and each user having different levels of trust and urgency may be associated with different default thresholds, defining allowable resources. In an example, the primary user device has an unlimited data plan but sets a predetermined threshold (i.e., limit) on data usage for borrowers at 1 GB of data per session. If the secondary user device requests 2 GB data, then the primary user device will not have sufficient resources to fulfill the request.

Examples of resources that may have constraints includes, but is not limited to, limits on data usage, connection time, applications permitted to access the Internet, etc. Once the constraints and restrictions are set, the primary user device accepts the incoming request with the identified restrictions, in block723. The secondary user device is then allowed connection to the primary user device via the mobile hotspot in block724. The primary user device stores the on-going transaction ledger, and periodic updates corresponding to the transaction, in the local and network ledger blockchain in block725. It should be noted that the primary user device can refuse to accept the connection if the borrower has a low level of trust, a low criticality or because the primary user determines another reason to decline.

FIG.8shows a flow chart of an exemplary method for incentivizing hotspot donors, in accordance with aspects of the present invention. In an embodiment, a potential donor receives a hotspot request in block801. The potential donor receives offers for incentives as motivation for accepting hotspot requests, in block802. Incentives may include, but are not limited to, free minutes as borrowers, cash or rebate offers from their mobile hotspot provisioning service provider based on data and time loaned out, additional Wi-Fi or broadband data or minutes, advertising-free minutes for services requiring the display of advertising to use the service or application, a bump up to a higher priority for a future borrowing request, etc. Incentives may be increased when loaning a mobile hotspot to users with a high urgency (e.g., criticality level). In other embodiments, incentives may be increased for requests of low urgency or unproven trust tiers to encourage donors to take more risk and allow non-urgent borrowing from strangers. This may promote more users to request bandwidth even if their usage is not critical, and promote new users with no proven trust levels to use the system. In an embodiment, the incentives may originate with the potential borrower. In an embodiment, the incentives originate from the mobile hotspot provisioning service.

The primary user device evaluates the trusted tier score for the incoming request and creates allowance constraints, in block803. In some cases, the primary user device would accept the secondary user request regardless of incentives, and any incentive is just an added bonus to being a donor. However, in borderline cases, the incentive offer may help sway the decision to accept. The primary user device evaluates the trusted tier score for the incoming request and creates allowance constraints in block804. In an embodiment, the primary user (donor) configures their device to accept borderline requests only when specific incentives are offered. In an example, Jane has only a limited amount of data in her pre-paid plan for the month, so she sets criteria for accepting requests that offer a 3-to-1 ratio of incentivized data to borrowed data. So, when an unknown user wants to borrow 1 MB of data, Jane will accept because she will receive 3 MB as incentive for a net gain of 2 MB. In embodiments, various criteria for incentives may be set for automatically accepting borrow requests. In another embodiment, a user must manually accept or reject the request based on a review of the inventive, trust level and urgency. In an embodiment, the primary user device may make a recommendation to the user whether to accept or reject the request, but the user manually selects to accept/reject.

When the automatic or manual criteria is acceptable, the primary user device accepts the request with restrictions, in block805. The primary user device and secondary user device are connected in block806. Once the connection is made, the user may receive the incentives offered, in block807. In an embodiment, incentives are automatically provided at commencement of the connection. In an embodiment, incentives are provided at the end of the connection. In an embodiment, the timing of receiving the incentives is based on the type of inventive offered. For instance, an offer of data bytes based on usage by the borrower cannot typically be provided until the connection is complete and the amount of data used is known. In another example, an offer of a flat 3 MB extra data for the donor's data plan can be provided as soon as the connection is made. The details of the mobile hotspot transaction are stored in the transaction ledger in block808. In an embodiment, incentive transactions are stored in the ledger in the blockchain. In another embodiment, incentives may be kept as private transactions between a user and service provider.

In embodiments, the mobile hotspot provisioning system can allow for navigation of one's smart mobile device for wireless connection through hotspot donors in a crowded community for light-weight selective “essential applications.” In order to avoid misuse of these types of resources and to enable a mutually beneficial outcome for all users, embodiments address concerns about security, sustainability, and trust. As discussed herein, embodiments provide a way for selective utilization of network bandwidth based on selection of applications in use and urgency in accordance with the rules configured by the user providing the service, thereby leading to application selective and contextual prioritization of network bandwidth in a seamless fashion. This also enables a higher level of control and security in the hands of the data provider.

Embodiments provide user specific restrictions on usage of certain applications based on sense of urgency, bandwidth requirement and criticality of the situation. The mobile hotspot provisioning system provides dynamic permission to certain applications deemed critical at that time with limited bandwidth cap in order to avoid misuse of the provider's (primary user) bandwidth/data network. This enables high security on the provider's end. In an embodiment, the primary user forms a network of certified people or devices that can be dynamically created with bandwidth/application allocation caps, thereby ensuring the provisioning of essential network data only to known user/users in need, in a dynamic fashion. This concept can be thought of as a contextual prioritization of network bandwidth based on criticality of the situation by users known to the primary user. Enacting a known/authorized user list enables more control to the primary user. In an embodiment, authorized users may include friends and family, friends of friends and family, groups of colleagues or people with defined common interest or memberships in organizations (i.e., colleagues at the same company, university, or special interest group), etc. In an embodiment, a primary user can allow connections with known and authorized users regardless of criticality if the requested bandwidth is available. In an embodiment, unknown users may also be authorized when they have historical ledgers in the blockchain to indicate a high level of trust.

In embodiments, criticality of the request is derived in block701(ofFIG.7A) before the request is sent by the secondary user.FIG.9shows a flow chart of an exemplary method for calculating the criticality level, in accordance with aspects of the present invention. In an embodiment, the secondary user device calculates the criticality of the request based on a 3-level urgency. In an example, C1 is the lowest priority, C2 is medium priority and C3 is high priority. In embodiments, one or more machine learning algorithms or models are used to determine criticality levels and generate a circle of trust among users. In an embodiment, a dataframe model is created using the primary user identification (PU_ID) and secondary user identification (SU_ID), priority columns and trust column. In an exemplary implementation, the priority columns are initially set as categorical feature vectors as Low, Medium, or High, in block901. They are encoded using a Label_Encoder function into numerical feature sets, in block902, and a dummy variable is taken care of using a Python Data Analysis Library (e.g., pandas library). In this example, C1: 0, C2: 1, and C3: 2. They are one-hot encoded into binary variables, in block903, such that if medium priority task needs to be done, priority column output can be merged using DataRefinery tool to showcase 010. In the context of the pandas library, One-hot Encoding is a type of vector representation in which all of the elements in a vector are 0, except for one, which has 1 as its value.

In an embodiment, an unsupervised machine learning algorithm such as K-means hierarchical clustering is used to measure distances between users. K-Means performs the division of objects into clusters that share similarities and are dissimilar to the objects belonging to another cluster. In this example, similar situations are clustered together based on the Euclidean distance of the labeled task with the unlabeled task newly arrived at the system, in block904. The K-means or hierarchical clustering is used in order to measure the Euclidean distance of the centroid with the criticality of the situation as the centroid and categorizing the secondary user's need to be clustered in one of the criticality clusters. A least squares adjustment (LSA) uses a term-document matrix which describes the occurrences of terms in documents containing said set of tasks in textual format, in block905. LSA is a general framework to determine unknown parameters based on given observations. A sparse matrix is created, in block906, whose rows correspond to terms and whose columns correspond to documents. Cosine similarity between those terms extract the symbolic value showcasing if a particular task needs to be clustered as 010, 100 or 001 or in case dummy variable function is applied, can be categorized as 00, 01 or 10 since 00 would signify C3 priority task. A circle of trust is generated, i.e., a database, list, or other data structure of users, each associated with a level of trust, in block907and discussed below corresponding toFIG.10.

Referring now toFIG.10, there is shown a flow chart of an exemplary method907for generating a circle of trust, in accordance with aspects of the present invention. A circle of trust is created using baseline random weights to users within the vicinity. A primary user device may generate a circle of trust for users in proximity. A secondary user device may update its circle of trust once it receives identifying information from primary user devices in the vicinity. In an embodiment, a secondary user device estimates a trust tier and updates the estimate after connecting to the Internet to retrieve current blockchain ledgers for users in proximity. In an embodiment, user identifications and trust tiers are stored locally on the user device so that secondary users have access to their circle of trust when off-line and cannot access the blockchain ledgers. In an embodiment, baseline models are uploaded in both the primary user device and secondary user device. The classification may be performed in both devices. The primary user device has flexibility to configure the inference and apply the classification in the decision process as whether to accept or reject the connection. For example, the primary user device may choose to always trust the requester, if the request comes from a user in the family. In another example, the primary user device may always run inference/classification by applying personalized settings or weights in order to classify the requests by the trust score.

Users in proximity to the user device are identified in block1001. In an embodiment, users of the mobile hotspot provisioning system may periodically broadcast to other users in the vicinity to announce that they are close and available. In another embodiment, the secondary user device broadcasts a ping message to devices in the vicinity and waits for acknowledgement messages from available primary user devices. The user device uses a multi-label classifier to categorize the potential other user into one of a plurality of tiers, in block1002. In an embodiment three tiers are used, labeled: T1, T2 or T3, wherein:T1: Close Family and friends,T2: Friends and colleagues, andT3: People in low priority circle.

Close family and friends may be given automatic high priority to use network bandwidth and a higher level of application usage based on the proximity of the primary user device to the secondary user device. Friends and colleagues may be given a medium priority to use network bandwidth and relatively limited number of applications as configured by the primary user device. Unknown and other users may be assigned a T3 priority. T3 users might be strangers in need of network usage, thereby providing configuration control in the hands of the primary user device to save the pattern history of the people in the T3 tier. The primary user device may impose restrictions based on the T3 tier status of those users. The restrictions may depend on the T3 user's needs, criticality and additional attributes accompanying the T3 user's contextual situation.

In an embodiment, initial weights are assigned to the three tiers, in block1003. In an example, a Keras library may be used to provide the weights. Keras is a free open source Python library for developing and evaluating deep learning models. Keras wraps the numerical computation libraries Theano and TensorFlow and allows a developer to define and train neural network models in just a few lines of code. Keras is used for creating deep models which can be productized on smartphones. In an embodiment, initial weights may be selected as random seeds and stored in the tier_class data construct. Keras may provide weights W1, W2, and W3 to the T1, T2, and T3 tier input parameters, respectively, using an exemplary function:keras.initializers.Initializer( )W1: 0.2W2: 0.4W3: 0.6

The user device polls the user's relationship, in block1004, using a previously defined LSA model (904-905,FIG.9) from scraping an online portal to access the contact and text information and feeds this to a text analytics model. In an example, the following may be used.page=urllib2.urlopen(mediapage/contact_UI)

Using the Python BeautifulSoup Library,soup=BeautifulSoup(page)soup.<tag>.
This procedure returns content between the opening and the closing tag including the tag indicating frequency, information between tags. In an embodiment, this information is provided to a text analytics LSA module, in block1005, to determine engagement level in scale weightage metric. Using information from the LSA module, a Keras library based artificial neural network (ANN) optimizer model performs back-propagation to re-allocate/retrain the weights W1, W2, W3. After n epochs, the training is complete and the weights associated with those tiers are classified via the ANN classifier into T1, T2 or T3 based on final values of the affinity weights.

Once the system has been trained, a circle of trust between entities in the vicinity is generated in block1006. User devices in the vicinity are ranked or prioritized based on the determined level of trust between the user device and the primary user device. The circle of trust is based on tiers and criticality. It will be understood that calculated weights provide an overall importance score to the secondary users in need of certain applications at a particular point of time inculcated with secondary user's tiered relation with the primary user to dynamically allocate an upper threshold of data (e.g., {data_upper-Y}) amount of network bandwidth and {A,B,C} applications that might be required by the secondary user and provided by the primary user with highest weights. It will also be understood that the primary user device can generate a circle of trust based on current blockchain data of potential borrowers and known users. It will also be understood that as user devices enter or leave the vicinity, or their historical transaction data changes, the generated circle of trust generated by the primary user device may change.

In embodiments, the computer server/device12(FIG.1) comprises mobile hotspot provisioning modules for both primary user and secondary user device functions, each of which may comprise one or more program modules such as program modules42described with respect toFIG.1. The user devices may include additional or fewer modules than those shown as operational blocks inFIGS.7A-BthroughFIG.10. In embodiments, separate modules may be integrated into a single module. Additionally, or alternatively, a single module may be implemented as multiple modules. Moreover, the quantity of devices and/or networks in the environment is not limited to what is shown inFIGS.4-6. In practice, the environment may include additional devices and/or networks; fewer devices and/or networks; different devices and/or networks; or differently arranged devices and/or networks than illustrated inFIGS.4-6.