PAYMENT INFRASTRUCTURE FOR MOBILITY

Techniques described herein include providing payment and access infrastructure for an array of transportation services, such as a set of transit or mobility services that might be provided by one or more governments, public agencies, and/or other public entities. In one example, this disclosure describes a method that includes enabling, by a computing system, a user to register for mobility benefits using a verification system, wherein the mobility benefits are provided by a provider entity; receiving, by the computing system and from the verification system, information about the user; establishing, by the computing system, an account linked to the provider entity; detecting, by the computing system, a request to access mobility benefits; allocating, by the computing system, funds from the account to pay for the mobility benefits.

TECHNICAL FIELD

This disclosure relates to computing systems, and more specifically, to techniques for providing access to and/or payment options for transit and mobility services.

BACKGROUND

Government entities have historically provided (or partnered with private entities to provide) transit services as a public service. As a result, many types of public transit services are available throughout the world, both within and across sovereign boundaries. Some governmental entities have made an effort to integrate their transit services for the convenience of the public. Often, however, many aspects of disparate transit services are not well integrated. For example, in some cities, paying to ride a bus within the city and paying to ride a train in that same city might require two different methods of payment.

SUMMARY

Techniques described herein include providing payment and access infrastructure for an array of transportation services, such as a set of transit or mobility services that might be provided by one or more governments, public agencies, and/or other entities. In some examples, techniques described herein include systems, processes, and services that might be provided by a bank or financial institution to implement access to transportation services through various payment processes and payment options. Such a bank or financial institution may also provide systems, infrastructure, services, and/or expertise in connection with implementing other aspects of a transportation infrastructure.

In general, techniques described may be applicable to a transit ecosystem that integrates a diverse array of transit options available to consumers of transit services in a particular geographic region. In addition, techniques described herein may be applicable across a diverse set of consumers. For example, for potential consumers of transit services that have limited access to banking services, techniques described herein may enable such consumers to nevertheless conveniently take advantage of transit services that might be provided by a government or other public entity. Similarly, for potential consumers of transit services that have limited access to a mobile smartphone or other mobile device, techniques described herein may enable such consumers to nevertheless take advantage of transit services that might be provided by a government or other public entity. And for potential consumers of transit services that have access to both banking services and modern mobile devices, techniques described herein enable efficient use of such banking services and mobile devices when using transit services.

Techniques described herein include architectures for arrangement of payment services, physical access techniques (e.g., turnstiles at a transit station), virtual access processes (e.g., biometric authentication), techniques for facilitating transportation that involves multiple transit systems (e.g., train, bus), accounting arrangements for allocating funds and/or limiting fund use to specific purposes, processes for encouraging use of transit system during periods of low utilization, processes for encouraging use of transit systems generally, techniques for providing transit consumers with convenient payment, funds allocation, and physical use of transit systems, as well as other techniques.

In some examples, this disclosure describes operations performed by a computing system in accordance with one or more aspects of this disclosure. In one specific example, this disclosure describes a method comprising enabling, by a computing system, a user to register for mobility benefits using a verification system, wherein the mobility benefits are provided by a provider entity; receiving, by the computing system and from the verification system, information about the user; establishing, by the computing system, an account linked to the provider entity; detecting, by the computing system, a request to access mobility benefits from the user; and allocating, by the computing system, funds from the account to pay for the mobility benefits.

In another example, this disclosure describes a system comprising a storage system and processing circuitry having access to the storage system, wherein the processing circuitry is configured to carry out operations described herein. In yet another example, this disclosure describes a computer-readable storage medium comprising instructions that, when executed, configure processing circuitry of a computing system to carry out operations described herein.

DETAILED DESCRIPTION

FIG.1is a conceptual diagram illustrating an example system for managing, integrating, and/or administering transit infrastructure, in accordance with one or more aspects of the present disclosure. System100ofFIG.1depicts a number of entities, organizations, and/or private enterprises. For example, illustrated in system100is government entity120, verification entity130, transit provider140, and administration entity170. For ease of illustration, only one government entity120, verification entity130, transit provider140, and administration entity170is shown inFIG.1. However, examples described herein may encompass scenarios or implementations in which any number of such entities may contribute to aspects of the techniques described herein.

FIG.1illustrates a variety of transit systems that may provide transit and/or mobility services to riders (hereinafter “users”). Such transit systems are represented inFIG.1as buses142A, trains142B, subways142C, and/or other transit systems142D (collectively “transit systems142”). Transit systems142may include various additional infrastructure used to implement transit services. Such additional infrastructure may include real estate, roads, railways, subway tunnels, airfields, and the like (not specifically illustrated inFIG.1). Such additional infrastructure may also include various buildings, structures, or transit access points, generally depicted inFIG.1as transit stations143A through143N (collectively “transit stations143”). Such transit stations143may be distributed throughout a geographical region served by any of transit providers140and/or transit systems142. Each of transit stations143may be operated by a specific transit provider140, and may provide access to a specific transit system142or to multiple transit systems142(or, in general, transit stations143may provide access to services provided by a specific transit provider140or to multiple transit providers140).

FIG.1also includes user101, intended to represent a rider or potential rider of one or more of transit systems142. In some examples, user101may possess and operate device111. In particular, user101may use or operate device111in connection with riding one or more of transit systems142. For example, user101may use device111to access benefits from government entities120, verify age and/or identity with verification entity130, and purchase or access transit services transit providers140.

Device111may be implemented by any suitable computing system including any mobile, non-mobile, wearable, and/or non-wearable computing device, which may be a mobile phone or tablet, or a laptop or desktop computing device. In general, device111may take any form, which may include a computerized watch, a computerized glove or gloves, a personal digital assistant, a virtual assistant, a gaming system, a media player, an e-book reader, a television or television platform, a bicycle, automobile, or navigation, information and/or entertainment system, or any other type of wearable, non-wearable, mobile, or non-mobile computing device that may perform operations in accordance with one or more aspects of the present disclosure. Alternatively, or in addition to using device111, user101may possess and use a smart, contactless, and/or other card162to perform some tasks (e.g., identification, authentication, payment) pertaining to riding one or more of transit systems142.

Other consumers of transit systems142include any number of other users101(not specifically shown inFIG.1) as well as secondary users102. Secondary users102may include various users that are affiliated with or related in some way to user101. For example, secondary users102may be family members of user101. Secondary users102may also include other users having some other relationship with a specific user101(secondary users102could include care providers, teachers, or guardians of a given user101, or co-workers, employees, or other users). One or more secondary users102may be, like user101, consumers of transit systems142. Such secondary users102may, in some examples, also operate a computing device and/or use a smart, contactless, and/or other card162.

Government entity120may be a local, state, or federal government or government agency that operates or administers one or more transit systems (e.g., transit systems142) within its jurisdiction. In most cases, such transit systems are public systems, operated by one or more public transit providers140. In some cases, however, such transit systems could include private transit systems, operated by privately-run transit providers140. In other cases, such transit systems may be implemented as a public/private entity partnership. Often, government entity120provides funding for one or more transit providers140, and may set or establish policy pertaining to costs for the use of transit services provided by transit providers140. In some cases, government entity120may establish policy to encourage use of transit service and/or to reduce or eliminate the costs to using such transit services for one or more segments of the population. For example, government entity120may establish policy that ensures that users without access to banking services and/or modern mobile devices can nevertheless conveniently use public transit services, perhaps at a reduced cost.

Verification entity130may be a public or private entity that authenticates users, and enables users to securely communicate with and/or access services provided by government entity120or other entities. In some examples, verification entity130may verify the identity, credit history, age, and other information about one or more users101. Verification entity130may supply credentials that enable users101to access mobility services provided by transit systems142, or that allow such users101to access online resources pertaining to transit systems142. Although illustrated as a separate entity inFIG.1, verification entity130may, in some examples, be part of another entity illustratedFIG.1(e.g., transit provider140may be part of government entity120, transit provider140, or administration entity170). In some examples, verification entity130may be a service like login.gov, which was a General Services Administration project of the United States government that was established to develop a secure, user-friendly way for the public to access government websites and services.

Transit provider140may be an agency or organization that administers, runs, or otherwise controls the operation of one or more transit systems142that provide mobility services to users in a given geographical region. As noted above, transit provider140is shown inFIG.1as a single entity, but system100may include multiple transit providers140. For example, one transit provider140may operate a fleet of busses142A, another transit provider140may operate light rail, commuter, or other train systems142B, another transit provider140may operate a subway systems142C, and other transit providers140may operate other transit systems.

Administration entity170may be a private company or other organization that facilitates, provides infrastructure, and/or provides payment processing services to enable users101to consume transit services within system100. For example, in some cases, administration entity170may be a bank or other financial institution that performs some aspects of financial and/or other administration of operations performed inFIG.1. In some examples, for instance, administration entity170establishes and/or maintains accounts for users101(e.g., financial accounts), allocates funds from government entity120to specific users using those accounts, and provides payment infrastructure that enables users to conveniently pay for transit services. In some cases, administration entity170might allocate funds from government entity120to an institutional account for that government entity120. In such an example, the administrative account may be used as a source of funds for providing mobility benefits to one or more users101.

InFIG.1, each of government entity120, verification entity130, transit providers140, and administration entity170may provide the services and perform the operations described herein through control and/or operation of various computing systems. Such computing systems are capable of communicating with other systems, devices, and/or entities illustrated inFIG.1over network105. For example, government entity120may control or operate one or more government computing systems121. Similarly, verification entity130may control and/or operate one or more verification computing systems131. Each of transit providers140may control and/or operate one or more transit provider computing systems141. In addition, administration entity170may control and/or operated one or more computing systems171. In each case, systems121,131,141, and171may be implemented as any suitable computing system or collection of computing systems, including one or more server computers, workstations, mainframes, appliances, cloud computing systems, and/or other computing devices that may be capable of performing operations and/or functions described in accordance with one or more aspects of the present disclosure. In some examples, such systems may represent or be implemented through one or more virtualized compute instances (e.g., virtual machines, containers) of a data center, cloud computing system, server farm, and/or server cluster. In these or other examples, such systems may be accessible over a network as a web service, website, or other service platform.

Each of transit stations143may include hardware devices and/or infrastructure relating to operation of specific transit system142(buses, trains, buildings, real estate). Such devices and/or infrastructure may include systems for enabling access (e.g., gates, turnstiles, card readers, ticketing booths, etc.) to transit system142by users101. In some examples, one or more of transit stations143may include one or more sensors144(e.g., transit station143A includes one or more sensors144A, and in general, transit station143N includes one or more sensors144N). Such sensors144may be any appropriate sensing device, and could include devices capable of sensing biometric attributes of user101. For example, such sensors144may include facial recognition systems, fingerprint or palm readers, retina scan systems, or any other biometric sensor now known or hereinafter developed. Such sensors144may be used to facilitate identification of user101and verification that each of user101is authorized or is permitted to access transit systems142and/or receive mobility services provided by one or more entities depicted in system100.

Although sensors144are shown inFIG.1as part of transit stations143, in other examples, one or more of sensors144may alternatively, or in addition, be associated with or included within any of transit systems142. For example, bus transit system142A may include a facial recognition system or a palm reader used by users when boarding one of buses142A. In another example, train transit system142B may include a camera that is used to identify users through facial recognition, or that is used merely for security or analytics purposes.

In the example ofFIG.1, any of the computing systems or devices illustrated may be capable of communicating over network105. Network105may include or represent any public or private communications network or other network, including the internet. Network105is intended to encompass any hardware or other systems required for enabling communications by computing systems and devices illustrated withinFIG.1or otherwise. To enable communication over105, various infrastructure devices encompassed by transit stations143or transit systems142may include communication devices and/or equipment. Accordingly, and although not specifically illustrated inFIG.1, transit stations143may include computing systems capable of communicating over network105with other systems. Similarly, the transit infrastructure that physically perform mobility services (e.g., the busses, trains, subway cars, or other mobile systems that transport users101) may be equipped with wireless communications devices enabling communication over network105with other systems, including any of those illustrated inFIG.1or described herein.

System100ofFIG.1may include other infrastructure relevant to provision of mobility services. Such infrastructure may include one or more retail outlets160and/or one or more ATM machines161. In some examples, retail outlets160may include publicly-run retail stores dedicated to transit services that may sell prepaid transit cards or enable reloading of transit cards with credits. In other examples, one or more of retail outlets160may include private retail stores dedicated to the sale of other goods or services (e.g., drugstores, grocery stores, gas stations), but that may also sell prepaid transit cards, enable reloading of transit cards with credits, or otherwise provide products and/or services to support use of transit systems142. In some cases, both retail outlets160and/or ATM machines161may be capable of dispensing one or more cards162customized for use by a specific user101.

In one example contemplated by this disclosure, system100may represent an environment in which government entity120is a state government seeking to integrate and/or modernize an array of transit systems142geographically distributed through the state. In such an example, administration entity170may be a bank that partners or collaborates with the state government entity120. Such a partnership or collaboration may enable administration entity170(i.e., the bank or financial institution) to provide payment, financial, or operational infrastructure, as well as services and/or expertise to state government entity120. Administration entity170may specifically be able to assist government entity120with making public transit more convenient, accessible, efficient, and self-sufficient. Administration entity170may also implement processes that allow for the efficient and equitable distribution of public funds to users101. In other words, government entity120may offer qualifying users101with mobility benefits, which may enable such users101to ride one or more transit systems142at a reduced rate or without cost.

Administration entity170may also provide systems, services, and/or expertise that make transit systems142accessible to those users101that wish to use transit systems142, but that have little or no access to a bank account (i.e., “unbanked” or “underbanked” users101). Administration entity170may provide systems and processes that enable unbanked, underbanked, and/or previously banked users101served by government entity120to pay for services provided by transit systems142and/or encourage users101that do not take advantage of services offered by transit to do so with the emergence of new payment solutions and experiences.

Although various examples described herein are described in terms of various entities (e.g., government entity120, verification entity130, transit provider140, administration entity170) performing specific tasks, it should be understood that in other examples, such tasks may be allocated to or performed by other entities than those described. For example, various tasks described as being performed by administration entity170herein could alternatively, or in addition, be performed by government entity120in other examples. Similarly, operations described herein as being performed by government computing systems121, verification computing systems131, transit provider computing systems141, and/or computing system171could alternatively be performed by other computing systems. For example, operations described herein as being performed by computing system171could alternatively, or in addition, be performed by any of computing systems121,131, or141.

In some examples, administration entity170may partner with government entity120to establish and implement processes and/or policies to that make participation in mobility programs simple and accessible, which will tend to encourage adoption and use of transit systems142. For instance, administration entity170may enable participation in mobility programs (and receipt of mobility benefits from government entity120) by requiring only minimal information (name, address, source of income). Identity verification of users101performed by administration entity170(i.e., through computing system171) may be bi-directional, and could use modern constructs, such as blockchain technologies. Existing verification services or websites (e.g., verification computing system131, operated by verification entity130) could also be leveraged, including services previously used by government entity120. In some cases, administration entity170may condition registration of user101on receiving an invitation from another referring user101. Such a referring user101could be verified by administration entity170(i.e., computing system171) as originating from a from a validated source. Administration entity170may also establish processes for auto-enrollment for “expected” or potential likely users (e.g., existing bank customers, seniors).

In some cases, administration entity170may establish that a heightened authentication process be used or even necessary at the point of registration, to ensure that enough information about a given user101is known. Such information can be used to address “know your customer” (“KYC”) requirements to enable a bank or other financial institution serving as administration entity170to meet anti-money laundering standards, regulatory requirements, or other requirements pertaining to providing financial services to a user. Such heightened information or authentication could equal or at least be similar to the level required to be authorized for an open-loop credit card that might be issued by a bank or financial institution (servicing as administration entity170). In some cases, payment capabilities might be enabled through a mobile device application executing on device111. Alternatively, or in addition, computing system171may enable payment capabilities through a newly-issued smart card162(e.g., dispensed at ATM machine161), thereby eliminating a requirement that user101have a bank account or device111. Payment capabilities could also be embedded into an existing government-issued identification card (or, possibly, an existing privately-issued card, such as a bank card or university card that might be offered by administration entity170). Such a card could be used merely as a payment tool (i.e., rather than an “account”), and could be prepaid, reloadable, or a combination of both.

For scenarios in which an account is established by administration entity170for some or all of users101, once a given user's identity has been verified and an account has been “opened” at a bank/administration entity170for the user, computing system171may communicate with other systems in system100. For example, computing system171may securely communicate with government computing system121, verification computing system131, and/or transit provider140over network105. Such communication may include information about accounts established for user101. Using this information, entities120,130, and/or140may automatically enroll user101in a program (e.g., administered by administration entity170or government entity120) that provides mobility benefits (e.g., public funds enabling user101to use transit systems142).

In some cases, identities of users101collected by verification entity130may be substantial enough to complete registration with the United States government through a service such as login.gov. In some cases, however, government entity120may include additional sources of identity (e.g. state IDs, employer verification) to address an expanded target resident population in the future. In such an example, government entity120may communicate additional information about user101to administration entity170(e.g., by enabling government computing system121to communicate such additional information over network105to computing system171). Such additional information may include resident identity information that government entity120and/or verification entity130has collected and verified and that administration entity170may require for “know your customer” or anti-money laundering purposes. Such information might be required to open a money movement account (resident name, address, source of income/wealth). This may be particularly important for unbanked and/or underbanked users101, since such users101may lack a substantial credit and/or account history. Also, government entity120may maintain the resident identities for users101, but government entity120and administration entity170may establish a federated identity solution (e.g., using a system similar to OpenID Connect). In some examples, administration entity170may maintain an aggregate/institutional account for the benefit of government entity120(or a specific entity) with a subledger that tracks balances for each of users101that ties to a payment vehicle (e.g. debit card).

Government entity120may, in some cases, provide Universal Basic Income (UBI) benefits to some of users101and/or secondary users102, which may involve establishing a bank account (e.g., at administration entity170) to enable such users101to receive income. Users101may pay for use of transit systems142using funds drawn from the account. In some examples, when user101pays for services provided by transit systems142, each of secondary users102associated with that user101may receive some form of fee forgiveness.

In one specific example, government entity120may establish a transit or mobility program that furnishes qualifying users a set amount of money each month to be used for public transportation. Government entity120may fund accounts for users101or for general population use through specific government allocations, employer contributions, or general public funds. In some cases, as described above, money could be deposited into a bank account and a given user101could use a newly-issued card that is to be used for transit. When user101signs up for such an account, that user might designate or choose a financial institution (from a network of banks or financial institutions) and may also provide any background information required by that financial institution, thereby satisfying any KYC requirements. In some cases, the chosen financial institution may serve as administration entity170.

As part of this process, information about user101or that user's benefits could be pre-filled or approved before being presented to user101(e.g., through a user interface presented by device111). After registration, features/benefits of the program could be ready to be delivered upon signup, thereby enhancing usability, reducing friction, and encouraging use. In registering for UBI, a user101may select which financial institution is to be used to manage balances and payments for that user101. Following the selection of the institution, government entity120may provide information to the financial institution or administration entity170(e.g., over network105). Thus, when user101visits a branch of the bank (administered by administration entity170) or signs up online, the amount of additional paperwork and effort is reduced as the financial institution (administration entity170) already has most of the records needed to open an account.

Additionally, employers can provide payments through the system for users, and may, in some cases, serve as a source of funds or information for government entity120. For example, an employer in the relevant geographical area may provide transportation benefits to offset the costs of commuting to an office as part of an employee's compensation package. Additionally, the employer can provide information to government entity120regarding an employee's income level and whether that employee would qualify for income-based transportation benefits.

In some examples, device111may execute an application developed for transit use with features as described herein. Such an application may be a newly-developed transit-specific app, but could also be an extension to an existing app. Such an application may be developed to make its use relatively seamless for those banked users101that are comfortable using smart/mobile devices (i.e., device111), and preferably much more user-friendly than legacy government-run programs.

For users101willing and/or able to use a mobile device app, additional benefits and conveniences might be available. Users may, for instance, receive notifications on device111for specific event-driven or destination-driven benefits that may be of value. For example, during heat wave, information about free bus rides to certain cooling centers might be distributed.

In some examples, envelopes, stashes, or sub-accounts can be used for specific purposes, and could be automatically established or allocated for various users101. Such automatic allocation (or self-assembly of envelopes) might be based on which benefits or envelopes a particular user101qualifies for, and this information could be derived from what administration entity170knows about a given user and that user's registration/qualifications. Such sub-accounts could also be sized by government entity120or an employer.

In some cases, it may be appropriate to limit the use of funds (e.g., narrow the use of funds to specific envelopes or limit to closed-loop scenarios) for users101identified as “risky,” those for which administration entity170has limited information, or those users have a limited KYC workup. To implement such limitations on fund use, administration entity170may use merchant category codes, or the user's location (e.g., a California resident can't use a transit card in New York). A payment system implemented by administration entity170could be configured to only approve payment based on the merchant code of the transaction, similar to how limitations on types of transactions work in the health savings account context (e.g., HSA cards). For example, user101might purchase a train ticket at a general retail outlet160, but administration entity170might prevent user101from purchasing other items such as food or household goods.

In some examples, purpose-specific funds could be used with an “account” established at administration entity170(demand deposit account, prepaid, etc.) and held by government entity120, but managed by user101. Such an account may be where financial benefits from government entity120will be deposited. User101can use the account to pay for state services (i.e., public transportation, EV, SNAP . . . ). That user's employer (or government entity120) may put money into these accounts directly. A state-held account and customer bank account could be reconciled daily to show total available balances.

Government entity120and/or administration entity170may establish policies to prevent a rider with limited funds from being stranded without access to transit systems142. For instance, computing system171may enable a “one more trip” policy that enables user101to carry a negative balance for one ride (or one trip, which may involve transfers). Such a policy would enable user101to return home safely, even while carrying negative balance.

In some examples, computing system171is implemented so that any signup process presented to users101is readily accessible when needed, so a user can enroll, receive benefits, and start using the benefits right at the bus station or other transit station143. A user might, for example, enroll for benefits from government entity120by accessing government computing system121over network105using device111and get a virtual card loaded with eligible benefits at a given transit station143. In some cases, user101might learn about benefits when visiting a transit station143and might see an advertisement with a QR code describing mobility benefits. User101might then scan the QR code using device111, launch an app that collects data to determine eligibility, and view information presented at device111about available benefits. If benefits are available, user101might push a virtual card to device111with funds loaded based on eligible benefits, making the benefits usable for a trip immediately on one or more of transit systems142.

For mobile application users, mobility benefits could be overlaid on maps in mapping apps executing on device111(e.g., Google Maps). In such an example, a map presented at device111could be annotated with mobility benefits, such as rewards available and costs, for various destinations chosen by the user. Similarly, mobility benefits could be integrated into a mobile device mapping app executing at device111.

For example, suppose user101wishes to travel from transit station143A to transit station143N (or generally, from point A to point B). User101might interact with a mapping application executing on device111and obtain directions using one or more of transit systems142. At that time, device111might also present a travel plan or itinerary, which might indicate that user101should walk to a specific identified bus stop or transit station143, ride a specific bus to a train station or other transit station143, and then take a specific train ride on train transit system142B. User101might also be presented with information indicating whether the user has enough mobility benefits (e.g., loaded on their mobile device, account, or physical debit card) to pay for the trip from transit station143A to transit station143N (or point A to point B).

System100ofFIG.1might use devices capable of sensing biometric attributes of users101. In some cases, artificial reality glasses or other AR/VR devices might be used as a device111or at transit stations143. In other cases, transit stations143may use biometric devices, such as a retina scan, for authentication. Watches, rings, voiceprints, also could be used, whether or not linked to a separate device111. In one example, user101might have an account holding transit dollars, and systems associated with transit options (the bus, subway, train, or any of transit stations143) could use facial recognition or palm sensors to allow that user to be identified and then travel using the transit dollars in the account.

In some cases, it may be useful to enable a digital payments network to be used as a sharing solution, so that if user101has mobility benefits, that user101can share or transfer those benefits with others, such as secondary users102(e.g., family members, employees, school children on a school field trip). In one example, when user101pays for transit services direct from a bank account (or otherwise), that user's family gets fee forgiveness for some period of time. In some examples, a single pool of funds might be shared by an entire family for transportation (i.e., one account, multiple users). Additionally, groups such as school field trips might be able to avoid having to pay or individually register children for reduced/free fares. Instead, the group as a whole can be registered for the reduced/free transit fares.

Some destinations within system100could be “free,” meaning transit costs to such destinations are not charged to some qualifying users (or not charged to any users). Free destinations might include public facilities, such as the local courthouse or library or other public facility. To prevent users from traveling to a “free” destination simply to avoid charges for traveling to “non-free” destination that is near a free destination (e.g., a restaurant across the street from the courthouse), a system at the free destination (where the “free” destination could operate as a transit station143) might be used to enable users to “check in” or “tap-in,” at which point transportation charges are reversed.

Some destinations might not be free, but could offer a discount or limited free availability (e.g., schools between certain morning hours on weekdays, enabling teachers to ride to work for free). Free or reduced cost rides could similarly be provided for seniors and/or for other users traveling to an appointment (e.g., a medical or government authorized appointment). In some cases, a fee forgiveness program could be implemented, where frequent riders receive benefits or discounts for volume transit (which may encompass travel by all family members). For example, for a family that travels four times per month, each family member receives a discount on the fifth and subsequent rides. Also, a referral program could be established to encourage others to use public transit (e.g., user101refers a friend who actually ends up using public transit, user101receives a free ride or $5 in benefits).

Administration entity170may establish policies to implement a deductible-like plan. For example, after user101uses transit systems142a threshold number of times, fees may be eliminated (or reduced). Until the threshold number of rides is reached, a fee might be incurred for each ride (acting as a “copay”). Administration entity170may establish policies that are more sophisticated, requiring computing system171to implement such policies using logic-based or rule-based algorithms. Such policies may be designed to encourage use of public transit.

Government entity120may partner with private services, like ride sharing services (e.g., Uber or Lyft), enabling users to allocate benefits to those services. Where benefits are government-provided, the Uber/Lyft driver may be effectively paid by the state in an arrangement where the state is effectively “renting” that service. Note that for some situations, like where there are a large number of riders, it may be more economical to user a ride sharing service than to use other transit systems142.

When providing benefits for private services, one or more transit systems142may condition such benefits on user101using some public transit. For example, if user101actually gets on the bus after getting out of the Uber/Lyft, computing system171may perform transactions that cause the connecting Uber/Lyft ride to be free for user101. The concepts described herein could encompass all forms of private transportation, beyond Uber/Lyft, and potentially extending to cab services, private bus lines, airlines, etc.

Mobility benefits provided by government entity120could be tied to peak/off-peak times, so that users receive more benefits immediately, or in the future, by scheduling transit use when public transit tends to be underused. Mapping software executing on device111may be used to help with this determination and steer users101into favorable timeframes. An app executing on device111might notify user101that user101has received $5 in benefits because of a ride taken during an off-peak timeframe.

Administration entity170could establish policies, implemented by computing system171, that tie incentives to user volumes at certain times of day (e.g., if a train from point of A to B is full at certain times of day, and basically empty at other times of day). In such an example, computing system171may reduce the fare automatically or confer more mobility benefits if the user travels during off-peak times. This concept might be considered to be similar policies in place for electric vehicle charging.

In some cases, using public transit frequently or for a period of time (e.g., a month) might result in some type of credit or reward. Those credits could be used for other public resources, like campgrounds, museums, or other sites. Computing system171may implement policies that make rewards useful in other areas, whether transportation related (e.g., airline miles or benefits within the state) or not (general benefits).

Administration entity170may receive interchange revenue by handling financial transactions within system100. In some examples, some or all of such revenue may be allocated to underserved groups, contributions to savings accounts to help build financial stability for various users101, and/or to further investments in public transit.

In some examples administration entity170may control and/or operate various ATM machines161within system100. In such an example, administration entity170may reconfigure existing ATMs to enable top-up or reloading of travel cards (in addition to app-based and website-based reloading). Closed loop (prepaid) systems could dispense cards162through the ATM. For users101who are bank customers of administration entity170, a variety of features and experiences may be tied into user accounts. For users101who are not customers, such users101might have limited capabilities to fund their accounts, get balances, etc. In some cases, a closed loop card (i.e., one that can be used only to pay for transit services) dispensed at an ATM might be convertible to an open-loop card (i.e., usable for non-transit services) based on the user providing other input and satisfying KYC requirements.

ATM machines161may serve a dual role as both an ATM machine and service station for transit-related tasks. ATM machines161may also adjust operations based on the type of card162a user101inserts into an ATM machine161. For instance, in an example that can be described in the context ofFIG.1, user101inserts card162into an ATM machine161. ATM machine161recognizes card162as a transit card (rather than a banking-related card, such as a debit card). In response, ATM machine161presents a user interface (e.g., display screen, interactive voice prompt) that presents transit-related information and/or services. Such transit-related information could involve providing a schedule of upcoming transit services that might be relevant to user101. Such transit-related services could involve enabling user101to obtain balance information, top-up or reload card162, dispense new cards162, or perform other transit-related functions. Where ATM machine161recognizes card162as a debit card, on the other hand, ATM machine161may present a user interface enabling ATM-related functions.

Enabling unbanked and/or underbanked users to use benefits (whether government-funded, employer-funded, or otherwise) to pay for public transit may be serve as the basis for establishing creditworthiness. By providing benefits, such users have the opportunity to build credit over time through contributions using transportation and mobility benefits. For example, if a user pays for some fraction of transit benefits, the user builds credit. If the state or other entity pays for such benefits, the user's credit score is not affected. In such examples, users101can build credit safely with micro-payments, locks, and controls. User101may use a card or an app to pay for transportation and then may use a credit card with locks and controls to immediately pay the fare when user101is enroute to the chosen destination.

In a system such as system100illustrated inFIG.1, government entities120and transit providers140can implement modern payment platforms (e.g., contactless platforms) and still avoid leaving behind users101who do not have access to smartphones or bank accounts. For example, transit providers140may provide options enabling all users101to pay for or reload transit cards in cash. Transit providers140should continue to allow users101to pay in cash to reload transit cards via vending machines or an outside retail network (e.g., retail outlets160). Transit providers140that are upgrading or implementing a payment system could still enable unbanked users101to refill their virtual accounts with cash at neighborhood convenience stores.

Transit providers140may also enable prepaid cards to operate with tap services. Prepaid, bank-branded cards are another option for users101for those users101that do not have a bank account or a smartphone. Transit providers140could partner with a prepaid-card program manager to provide prepaid cards to the provider's unbanked ridership, or transit providers140could issue privately labeled cards in partnership with a bank and processing company.

Transit providers140may also provide protections for users101having a negative balance. When a transit fare is higher than the amount left on a card162, this negative balance could prevent user101from exiting a transit station143. A policy that enables user101to take one more trip on a bus when they have a negative balance would prevent such a result.

Transit providers140could make moving between cities simple and easy. Often, legacy transit systems142may make moving between cities involve moving between operators with different payment mediums. Transit providers140could integrate the payment processes and enable users101to use payment mediums interchangeably, or at least simple and easy.

Transit providers140could replace legacy payment systems and agency-issued tickets or cards with fully digital open-loop payments systems, which accept all debit, credit, and mobile payments and are more readily interoperable between different transit agencies and shared mobility operators. This would enable transit users to pay for transit with whichever means of payment they prefer. However, some considerations—such as ‘know your customer’ requirements—may mean open payment solutions might not be able to serve all customer segments. In some cases, if a transit operator (e.g., any of transit providers140) plans to offer payment media that can be used outside of transit, significant marketing effort may be needed to position those products as a universal payment solution instead of transit smartcards.

Transit providers140should establish policies based on an assumption that banked and unbanked users101both want to pay for transit with the same means of payment they already use for other things. Similarly, transit providers140should establish policies based on an assumption that, for the most part, unbanked users101are not deterred from using digital payments for transit. Unbanked and lower income individuals are more likely to indicate they would use prepaid cards (government issued or otherwise), and less likely to use other means. Whereas those who are banked are more likely to indicate they would use mobile phone-based payments and debit cards.

Techniques described herein may provide certain technical advantages. For instance, by modernizing payment platforms, transit systems142may operate more reliably and in a more cost-effective and automated way, perhaps while still requiring fewer employees and other resources. Further, by integrating payment and other processes across multiple disparate transit systems142, users101will more effectively be able to use a diverse set of transit systems142and reach destinations more quickly and efficiently. Further, by modernizing payment platforms in a way that ensures access to transit systems by all segments of the population, transit systems will be more widely used across all demographics, and thereby better serve the public.

Transit and mobility systems and related benefits are one primary use case contemplated by systems, techniques, and processes described herein. As described herein, such systems may be implemented through a collaboration between a governmental entity (e.g., a state government) and a financial institution (e.g., a banking institution). However, other government benefits or services beyond transit could follow a similar program or pattern. Further, such programs could involve a collaboration with another type of private entity, or, in some cases without a collaboration with any private entity. Accordingly, concepts described herein could apply to other governmental programs and other allocations of public funds. Such public funds might or might not include allocations of purpose-driven funds for a specific purpose.

FIG.2Ais a conceptual diagram illustrating a process by which a user registers to pay for transit services using a credit card, in accordance with one or more aspects of the present disclosure. Operations illustrated inFIG.2Aare described herein within the context of system100ofFIG.1, and represent one possible way in which users101may register to pay for transit services in system100.

InFIG.2A, and in accordance with one or more aspects of the present disclosure, user101may start a registration process established by government entity120(201). For instance, in an example that can be described with reference toFIG.1, device111(operated by user101) detects input and outputs a signal over network105. Government computing system121of detects a signal over network105and determines that the signal corresponds to a request, by user101operating device111, to register for transit services benefits.

Verification entity130may verify the user's identity (202). For instance, continuing with the example and with reference toFIG.1, government computing system121outputs signals over network105. Device111detects the signals over network105. In response to the signals, device111begins interacting with verification computing system131. Based on such interactions, which may be derived from input detected at device111(e.g., from user101), verification computing system131verifies the identity of user101.

Verification entity130may verify the user's age (203). For instance, still with reference toFIG.1, and based on further interactions between device111and verification computing system131, verification computing system131collects further information about user101. Based on this further information, verification computing system131verifies the age of user101.

Transit provider140may store payment information (204). For instance, still continuing with the example being described in the context ofFIG.1andFIG.2A, verification computing system131outputs further signals over network105after verifying the identity and age of user101. Device111detects the further signals over network105and determines that the signals correspond to a request for payment information. Device111detects input and outputs information over network105. Verification computing system131receives the information and determines that the information includes credit card payment information for user101. Verification computing system131stores the credit card payment information (e.g., credit card number and security code) for use in connection with transit services provided in system100by one or more of transit systems142.

Each of transit systems142may link transit benefits or discounts to the stored payment information (205). For instance, again with reference toFIG.1, and after verification computing system131collects payment information, verification computing system131outputs signals over network105. Government computing system121detects the signals and determines that the signals correspond to a request for information about mobility or transit benefits available for the verified user101from government entity120. Government computing system121responds to the request with information about mobility or transit benefits. Verification computing system131receives the information and communicates information about the mobility or transit benefits to one or more transit provider computing systems141over network105. Each of transit provider computing systems141detect one or more signals and determine that the information includes information that links transit benefits to use of the credit card of user101.

FIG.2Bis a conceptual diagram illustrating a process by which a user uses a credit card to pay for transit services, in accordance with one or more aspects of the present disclosure. Operations illustrated inFIG.2Bare described herein within the context of system100of FIG.1, and represent one way in which user101may pay for transit services provided by transit provider140A (through transit system142A) in system100using a credit card.

InFIG.2B, and in accordance with one or more aspects of the present disclosure, user101visits transit station143A (seeFIG.1), seeking to use transit services (211). Sensor144A at transit station143A detects an interaction (e.g., a tap, swipe) with a credit card (212). Sensor144A outputs information about the interaction to transit provider computing system141A operated by transit provider140A. Transit provider computing system141A uses the information about the interaction to identify user101.

Transit provider computing system141A determines whether user101is entitled to any mobility benefits from government entity120(213). For example, again referring toFIG.1and based on the determination of whether user101is entitled to mobility benefits, transit provider computing system141A processes payment for the requested transit services provided by transit provider140A. In some cases, some or all of such payment is charged to the card associated with user101. In other cases, some or all of such payment is provided through funds allocated by government entity120.

FIG.3is a conceptual diagram and block diagram illustrating an example computing system for managing, integrating, and/or administrating transit infrastructure, in accordance with one or more aspects of the present disclosure. System300ofFIG.3includes many of the same elements of system100ofFIG.1, and in general, like-numbered elements illustrated inFIG.3correspond to elements similarly illustrated and numbered inFIG.1.

FIG.3does, however, illustrate a block diagram of computing system271. In examples described in connection withFIG.3, computing system271may correspond to, or may be considered an example or alternative implementation of computing system171ofFIG.1. For ease of illustration, computing system271is depicted inFIG.3as a single computing system. However, in other examples, computing system271may comprise multiple devices or systems, such as systems distributed across a data center or multiple data centers. For example, separate computing systems may implement functionality performed by each of user interface module281, account module282, and payment module283. Alternatively, or in addition, computing system271(or various modules illustrated inFIG.3as included within computing system271) may be implemented through distributed virtualized compute instances (e.g., virtual machines, containers) of a data center, cloud computing system, server farm, and/or server cluster.

InFIG.3, computing system271is illustrated as including underlying physical hardware that includes power source279, one or more processors273, one or more communication units275, one or more input devices276, one or more output devices277, and one or more storage devices280. Storage devices280may include user interface module281, evaluation module282, and refinement module283. One or more of the devices, modules, storage areas, or other components of computing system271may be interconnected to enable inter-component communications (physically, communicatively, and/or operatively). In some examples, such connectivity may be provided by through communication channels, which may include a system bus (e.g., communication channel272), a network connection, an inter-process communication data structure, or any other method for communicating data.

Power source279of computing system271may provide power to one or more components of computing system271. One or more processors273of computing system271may implement functionality and/or execute instructions associated with computing system271or associated with one or more modules illustrated herein and/or described below. One or more processors273may be, may be part of, and/or may include processing circuitry that performs operations in accordance with one or more aspects of the present disclosure. One or more communication units275of computing system271may communicate with devices external to computing system271by transmitting and/or receiving data, and may operate, in some respects, as both an input device and an output device. In some or all cases, communication unit275may communicate with other devices or computing systems over network305or over other networks.

One or more input devices276may represent any input devices of computing system271not otherwise separately described herein, and one or more output devices277may represent any output devices of computing system271not otherwise separately described herein. Input devices276and/or output devices277may generate, receive, and/or process output from any type of device capable of outputting information to a human or machine. For example, one or more input devices276may generate, receive, and/or process input in the form of electrical, physical, audio, image, and/or visual input (e.g., peripheral device, keyboard, microphone, camera). Correspondingly, one or more output devices277may generate, receive, and/or process output in the form of electrical and/or physical output (e.g., peripheral device, actuator).

One or more storage devices280within computing system271may store information for processing during operation of computing system271. Storage devices280may store program instructions and/or data associated with one or more of the modules described in accordance with one or more aspects of this disclosure. One or more processors273and one or more storage devices280may provide an operating environment or platform for such modules, which may be implemented as software, but may in some examples include any combination of hardware, firmware, and software. One or more processors273may execute instructions and one or more storage devices280may store instructions and/or data of one or more modules. The combination of processors273and storage devices280may retrieve, store, and/or execute the instructions and/or data of one or more applications, modules, or software. Processors273and/or storage devices280may also be operably coupled to one or more other software and/or hardware components, including, but not limited to, one or more of the components of computing system271and/or one or more devices or systems illustrated or described as being connected to computing system271.

Data store289of computing system271may represent any suitable data structure or storage medium for storing information relating to accounts maintained for users101, verification processes for verifying, authenticating, and/or auditing use of transit systems142by users101, funding sources and policies for use of transit systems142, and other information pertaining to the administration of system300ofFIG.3or aspects of system300. The information stored in data store289may be searchable and/or categorized such that one or more modules within computing system271may provide an input requesting information from data store289, and in response to the input, receive information stored within data store289. Data store289may be primarily maintained by account module282.

User interface module281may perform functions relating to presenting one or more user interfaces to users101(e.g., through devices111) or receiving information derived from input detected at devices111. In some examples user interfaces presented by user interface module281may include information about transit fares, locations of transit stations143, information about schedules for various transit systems142, information about discounted fares or mobility benefits provided by government entity120, maps or annotated maps illustrating routes and costs associated with a trip, and other information. Account module282may perform functions relating to maintaining one or more accounts for each of users101or, in some cases, for government entity120. Payment module283may perform functions relating to processing payment for fares charged to users101for trips taken within system100using transit systems142. Payment module283may apply algorithms for calculating fares that tend to encourage use of transit systems142that enforce a policy established by government entity120. Payment module283may also provide information to user interface module281to enable user interface module281to generate notifications or information to be presented to one or more users101about costs for use of transit systems142.

Modules illustrated inFIG.3(e.g., user interface module281, account module282, payment module283) and/or illustrated or described elsewhere in this disclosure may perform operations described using software, hardware, firmware, or a mixture of hardware, software, and firmware residing in and/or executing at one or more computing devices. For example, a computing device may execute one or more of such modules with multiple processors or multiple devices. A computing device may execute one or more of such modules as a virtual machine executing on underlying hardware. One or more of such modules may execute as one or more services of an operating system or computing platform. One or more of such modules may execute as one or more executable programs at an application layer of a computing platform. In other examples, functionality provided by a module could be implemented by a dedicated hardware device.

Although certain modules, data stores, components, programs, executables, data items, functional units, and/or other items included within one or more storage devices may be illustrated separately, one or more of such items could be combined and operate as a single module, component, program, executable, data item, or functional unit. For example, one or more modules or data stores may be combined or partially combined so that they operate or provide functionality as a single module. Further, one or more modules may interact with and/or operate in conjunction with one another so that, for example, one module acts as a service or an extension of another module. Also, each module, data store, component, program, executable, data item, functional unit, or other item illustrated within a storage device may include multiple components, sub-components, modules, sub-modules, data stores, and/or other components or modules or data stores not illustrated.

Further, each module, data store, component, program, executable, data item, functional unit, or other item illustrated within a storage device may be implemented in various ways. For example, each module, data store, component, program, executable, data item, functional unit, or other item illustrated within a storage device may be implemented as a downloadable or pre-installed application or “app.” In other examples, each module, data store, component, program, executable, data item, functional unit, or other item illustrated within a storage device may be implemented as part of an operating system executed on a computing device.

FIG.4Ais a conceptual diagram illustrating a process by which a user registers to pay for transit services using an alternative payment method, in accordance with one or more aspects of the present disclosure. Operations illustrated inFIG.4Aare described herein within the context of system300ofFIG.3, and represent one possible way in which users101may register to pay for transit services in system300. In some examples, users101inFIG.4Amay register for mobility benefits provided by government entity120.

FIG.4Adiffers fromFIG.2Ain some respects. For example, rather than requiring user101to enter credit card information, a bank or other financial institution (e.g., administration entity170) may use information provided by government entity120(e.g., via an API exposed by computing system271) to establish an “account” at the bank or financial institution. Accordingly, at least some aspects of computing system271may be operated and/or controlled by a bank or other financial institution (i.e., administration entity170inFIG.3can be a bank or other financial institution). In some examples, the “account” established at administration entity170is not necessarily a fully-enabled or normal bank account, but might instead be an account that can be used to link to transit benefits from government entity120. In some cases, the “account” might be a hybrid between an institutional account and individual consumer accounts, where funds are drawn from an institutional account into a user account, as needed.

Further, in some examples, the account established at administration entity170for user101may include or may enable sub-accounts or stashes that hold funds to be used for a specific purpose (e.g., transit services). Funds could be allocated as needed from government entity120or from an account associated with government entity120. In some examples, a batch reconciliation could be performed periodically (e.g., at the end of the day). Such an implementation might parallel some “university card” programs offered by commercial banks to college students. Alternatively, or in addition, such an implementation might leverage user information derived from data collected by the login.gov system. Some implementations could, in some cases, involve a full “know your customer” (KYC) work-up that requires a user to provide substantial background information in exchange for establishing an account and/or issuing a payment card to be used for transit services.

InFIG.4A, and in accordance with one or more aspects of the present disclosure, computing system271ofFIG.3may initiate or enable a registration process for a user (401). For instance, with reference toFIG.3andFIG.4A, device111(operated by user101) detects input and outputs a signal over network105. Communication unit275of computing system271detects a signal and outputs information about the signal to user interface module281. User interface module281determines that the signal corresponds to a request, by user101, to register for transit or mobility benefits that may be available through government entity120.

Computing system271may enable verification entity130to verify user101(402). For instance, again with reference toFIG.3, user interface module281of computing system271causes communication unit275to output signals over network105. Device111detects signals over network105and based on the signals, presents a user interface at device111. Device111detects interactions with the presented user interface and communicates with verification computing system131over network105. Verification computing system131verifies, based on communications with device111over network105, the identity, age, and/or income level of user101.

Administration entity170may receive, through computing system271, information about user101(403). For instance, continuing with the example being described in the context ofFIG.3, verification computing system131outputs a signal over network105. Communication unit275of computing system271detects the signal over105and outputs information about the signal to account module282. Account module282determines that the signal includes information from verification entity130(i.e., verification computing system131). Account module282further determines that the information includes information about the identity, age, and/or income level of user101.

Computing system271may establish an account (404). For instance, again referring toFIG.3, account module282uses one or more application programming interface (API) calls to establish an account for user101at administration entity170. Account module282causes communication unit275to interact with government computing system121over network105. Based on such interactions, account module282determines whether transit services benefits are available to user101. Account module282establishes account285for user101and stores information about the account in data store289. Account module282links account285to transit benefits provided by government entity120(e.g., based on the interactions with government computing system121).

Computing system271may produce a debit card to enable user101to use transit services (405). For instance, still referring toFIG.3, account module282outputs information to payment module283. Payment module283funds account285, drawing funds from government entity120as a result of interactions with government computing system121. In some examples, payment module283of computing system271may cause one or more cards162to be established or created. Each such162may be issued by administration entity170and funded from account285. Card162may, for example, be a contactless debit card for the use by users101authorized to use account285(e.g., user101and/or secondary users102). In some cases, such cards162may be physically provided to user101(e.g., by physical delivery, or through one of ATM machines161).

FIG.4Bis a conceptual diagram illustrating a process by which a user uses an alternative payment method to pay for transit services, in accordance with one or more aspects of the present disclosure. Operations illustrated inFIG.4Bare described herein within the context of system300ofFIG.3, and represent one way in which users101may pay for transit services in system300using an alternative payment method established through the process described in connection withFIG.4A.

InFIG.4A, and in accordance with one or more aspects of the present disclosure, user101visits transit station143A, seeking to use one or more transit services and/or mobility benefits (411). For instance, with reference to an example that can be described in the context ofFIG.3, user101brings card162to transit station143A, seeking to access transit services provided by, for example, transit provider140A.

Computing system271may detect input enabling identification of verified user101(412). For instance, continuing with the example, sensor144A at transit station143A detects input that it determines corresponds to a tap, swipe, or other action involving card162. Sensor144A outputs a signal over network105. Communication unit275of computing system271detects a signal over network105and outputs information about the signal to payment module283. Payment module283determines that the signal includes information identifying card162. Payment module283uses the information to identify and access account285associated with user101. Payment module283determines, based on account285, that user101qualifies for mobility benefits and/or has sufficient funds to access the desired transit services.

Computing system271may enable the user to access to transit services (413). For instance, again referring toFIG.3, payment module283causes communication unit275to output a signal over network105. Transit station143A receives a signal over network105and determines that the signal is a command to enable the requested transit services for user101(i.e., enable user101to ride the bus, train, subway). Transit station143A enables transit services for user101(e.g., by providing access to user101through a turnstile at transit station143A, by providing an indication to the driver of one of buses142A that appropriate payment for user101has been received, or through some other appropriate method). Payment module283also determines one or more transactions to apply to account285associated with the transit services user101is accessing. Payment module283updates account285to account for the transit services used by user101and to account for any benefits applied to pay for the transit services. In some examples, such updates may include deducting funds, adding funds from a source of mobility benefits, applying discounts associated with mobility benefits, and/or applying other adjustments to account285. Payment module283outputs information to data store289, causing data store289to log information about transactions associated with the transit services used by user101. In some examples, user interface module281may cause communication unit275of computing system271to output a signal over network105that device111uses to present a user interface (e.g., providing to user101information about payment).

FIG.5is a conceptual diagram illustrating a process by which a financial institution allocates funds for transit services to users, in accordance with one or more aspects of the present disclosure. InFIG.5, administration entity170described and illustrated inFIG.1andFIG.3may be a bank or other financial institution that performs financial, operational, and other tasks for various services in collaboration with government entity120. In the example illustrated inFIG.5, government entity120may be the State of California, and the services described may be transit services throughout the state.

Various account maintenance arrangements may be established between government entity120and administration entity170. In some examples, funds could be held on behalf of each user101(i.e., each “rider” or “customer”) by administration entity170. In other examples, a single unified account could be used for a group of users101(e.g., administered by computing system171A), and those funds could be allocated to users through subaccounts (administered by computing system171B). Alternatively, instead of administration entity170holding “funds” for the purposes of transit, users101could be furnished with a predefined count or quantity of “free” trips that can be taken, either indefinitely or within a time-boxed period of time (e.g.,40trips per month, which equates to 2 trips per day, 5 days per week, 4 weeks in a month).

Other arrangements might use “ringfenced” purpose-specific funds within an “account” (inclusive of demand deposit accounts, prepaid, and other bank instruments). In such examples, the funds might not actually be ‘housed’ within the account holder's underlying account. Instead, the funds may be held in an institutional account (e.g., for government entity120or an agency thereof) but be linked to the user's payment vehicle (e.g., debit card) and available on-demand and reconciled in real-time or end-of-day (batch) between accounts with the ‘available’ balance shown to the user through digital interface and/or statement enabled or provided by government entity120and/or administration entity170.

The funds could be purpose-specific (e.g., transit, SNAP, Electronic Benefits Transfer, gas inflation reduction, electric vehicle charging/reimbursement), and the merchant classification code could be provided by the payment network. Such a code could be used to drive decisioning in real-time by a computing system (e.g., computing system171B inFIG.5) around where to pull funds from (e.g., a transit ‘stash’ would be deducted if a transaction matching a transit specific merchant name was made; otherwise, the transaction would draw from a general balance).

In general, any given user101might not have access to these ‘ringfenced’ funds for general spending (e.g., if user101overdraws a general funds balance, these funds are not a ‘fallback’ or ‘grace’ balance). A ringfenced ‘stash’ would generally be funded by an external entity, such as government entity120or an employer—this could replace the way pre-tax transit benefits, health savings accounts, and other accounts work today. In another example, and in the case of a ‘general’ disbursement (e.g., COVID stimulus, universal basic income, tax refund), the funds could flow down the same ‘rails’ but would be deposited in the user's general funds/balance for spending on anything (no restrictions)—the ‘funder’ could determine the type of payment at the time of payment.

FIG.6is a flow diagram illustrating operations performed by an example computing system in accordance with one or more aspects of the present disclosure.FIG.6is described below within the context of computing system170ofFIG.1. In other examples, operations described inFIG.6may be performed by one or more other components, modules, systems, or devices. Further, in other examples, operations described in connection withFIG.6may be merged, performed in a difference sequence, omitted, or may encompass additional operations not specifically illustrated or described.

In the process illustrated inFIG.6, and in accordance with one or more aspects of the present disclosure, computing system171may enable a user to register for mobility benefits (601). For example, with reference toFIG.1, computing system171detects signals over network105that it determines corresponds to a request, by a user operating device111, to register for mobility benefits provided by government entity120. Computing system171outputs signals over105that cause device111to interact with verification computing system131and verify the age, identity, and other information about user101.

Computing system171may receive information about user101(602). For example, verification computing system131verifies information about the age, identity, and other information about user101, through interactions with device111over network105. Verification computing system131outputs signals over network105. Computing system171detects signals over network105and determines that the signals include information about user101.

Computing system171may establish an account (603). For example, computing system171uses the information about user101to determine what extent, if any, user101is entitled to mobility benefits offered by government entity120. In some examples, computing system171may interact with government computing system121to perform such a determination. Computing system171establishes an account for user101, where the account may be configured differently based on whether user101is entitled to certain mobility benefits from government entity120.

Computing system171may receive a request to use mobility benefits (604). For example, computing system171waits for a signal over network105(NO path from604). Eventually, user101visits transit station143A and interacts with one or more sensors144A at transit station143A. One or more of sensors144A output a signal over network105. Computing system171detects a signal over network105and determines that the signal corresponds to a request, by user101to use transit system142at transit station143A (YES path from604).

Computing system171may allocate funds to pay for mobility services (605). For example, computing system171determines, based on the type of account previously established for user101, how payment for mobility services provided by transit system142A should made. In some examples, computing system171determines that user101is entitled to mobility benefits, and in such an example, some or all of the funds required for the requested transit services are allocated from funds originally provided by government entity120. In other examples, computing system171may determine that user101is not entitled to mobility benefits, and in such an example, some or all of the funds required for the requested transit services area allocated from funds originally provided by user101through other sources.

For processes, apparatuses, and other examples or illustrations described herein, including in any flowcharts or flow diagrams, certain operations, acts, steps, or events included in any of the techniques described herein can be performed in a different sequence, may be added, merged, or left out altogether (e.g., not all described acts or events are necessary for the practice of the techniques). Moreover, in certain examples, operations, acts, steps, or events may be performed concurrently, e.g., through multi-threaded processing, interrupt processing, or multiple processors, rather than sequentially. Further certain operations, acts, steps, or events may be performed automatically even if not specifically identified as being performed automatically. Also, certain operations, acts, steps, or events described as being performed automatically may be alternatively not performed automatically, but rather, such operations, acts, steps, or events may be, in some examples, performed in response to input or another event.

The disclosures of all publications, patents, and patent applications referred to herein are hereby incorporated by reference. To the extent that any such disclosure material that is incorporated by reference conflicts with the present disclosure, the present disclosure shall control.

For ease of illustration, only a limited number of devices (e.g., device111, government computing system121, verification computing system131, transit provider computing system141, computing system171, computing system271, as well as others) are shown within the Figures and/or in other illustrations referenced herein. However, techniques in accordance with one or more aspects of the present disclosure may be performed with many more of such systems, components, devices, modules, and/or other items, and collective references to such systems, components, devices, modules, and/or other items may represent any number of such systems, components, devices, modules, and/or other items.

The Figures included herein each illustrate at least one example implementation of an aspect of this disclosure. The scope of this disclosure is not, however, limited to such implementations. Accordingly, other example or alternative implementations of systems, methods or techniques described herein, beyond those illustrated in the Figures, may be appropriate in other instances. Such implementations may include a subset of the devices and/or components included in the Figures and/or may include additional devices and/or components not shown in the Figures.

The detailed description set forth above is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a sufficient understanding of the various concepts. However, these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in the referenced figures in order to avoid obscuring such concepts.

Accordingly, although one or more implementations of various systems, devices, and/or components may be described with reference to specific Figures, such systems, devices, and/or components may be implemented in a number of different ways. For instance, one or more devices illustrated herein as separate devices may alternatively be implemented as a single device; one or more components illustrated as separate components may alternatively be implemented as a single component. Also, in some examples, one or more devices illustrated in the Figures herein as a single device may alternatively be implemented as multiple devices; one or more components illustrated as a single component may alternatively be implemented as multiple components. Each of such multiple devices and/or components may be directly coupled via wired or wireless communication and/or remotely coupled via one or more networks. Also, one or more devices or components that may be illustrated in various Figures herein may alternatively be implemented as part of another device or component not shown in such Figures. In this and other ways, some of the functions described herein may be performed via distributed processing by two or more devices or components.

Further, certain operations, techniques, features, and/or functions may be described herein as being performed by specific components, devices, and/or modules. In other examples, such operations, techniques, features, and/or functions may be performed by different components, devices, or modules. Accordingly, some operations, techniques, features, and/or functions that may be described herein as being attributed to one or more components, devices, or modules may, in other examples, be attributed to other components, devices, and/or modules, even if not specifically described herein in such a manner.

Although specific advantages have been identified in connection with descriptions of some examples, various other examples may include some, none, or all of the enumerated advantages. Other advantages, technical or otherwise, may become apparent to one of ordinary skill in the art from the present disclosure. Further, although specific examples have been disclosed herein, aspects of this disclosure may be implemented using any number of techniques, whether currently known or not, and accordingly, the present disclosure is not limited to the examples specifically described and/or illustrated in this disclosure.

By way of example, and not limitation, such computer-readable storage media can include RAM, ROM, EEPROM, or optical disk storage, magnetic disk storage, or other magnetic storage devices, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection may properly be termed a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using a wired (e.g., coaxial cable, fiber optic cable, twisted pair) or wireless (e.g., infrared, radio, and microwave) connection, then the wired or wireless connection is included in the definition of medium. It should be understood, however, that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transient media, but are instead directed to non-transient, tangible storage media.

Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the terms “processor” or “processing circuitry” as used herein may each refer to any of the foregoing structure or any other structure suitable for implementation of the techniques described. In addition, in some examples, the functionality described may be provided within dedicated hardware and/or software modules. Also, the techniques could be fully implemented in one or more circuits or logic elements.