Abstract: Rules can be selectively applied by a user to an access card using a graphical user interface (GUI) of a mobile application. For example, the mobile application can provide a graphical user interface through which the user can select how usage of the access card is to be handled by the service provider. The mobile application can receive, through the graphical user interface, input from the user indicating one or more rules to be applied to the access card. The one or more rules can dictate how usage of the access card is to be handled by the service provider. In response to receiving the input, the mobile application can transmit one or more commands to a computer system associated with the service provider. The computer system can receive the one or more commands and implement the one or more rules selected by the user of the access card.

Abstract: Rules can be selectively applied by a user to an access card using a graphical user interface (GUI) of a mobile application. For example, the mobile application can provide a graphical user interface through which the user can select how usage of the access card is to be handled by the service provider. The mobile application can receive, through the graphical user interface, input from the user indicating one or more rules to be applied to the access card. The one or more rules can dictate how usage of the access card is to be handled by the service provider. In response to receiving the input, the mobile application can transmit one or more commands to a computer system associated with the service provider. The computer system can receive the one or more commands and implement the one or more rules selected by the user of the access card.

Abstract: Card controls can be selectively applied by a user to a card using a graphical user interface (GUI). The card controls can dictate whether network requests associated with usage of the card are to be handled using an account subsystem or a service subsystem. For example, the user can input a first selection to the GUI for applying a first card control in relation to a first type of network request. Based on the first selection, the system can be configured to complete network requests of the first type using the service subsystem. The user can also input a second selection to the GUI for applying a second card control in relation to a second type of network request. Based on the second selection, the system can be configured to complete network requests of the second type using the account subsystem.

Abstract: Network requests can be automatically routed between two or more computer subsystems in some examples. In one such example, a system can determine that a user is eligible for a service based on usage data relating to an account of the user. Based on determining that the account is eligible for the service, the system can activate the service for the user by communicating with a service subsystem. Subsequent to activating the service for the user, the system can receive a network request associated with the user and determine that the network request has a characteristic. Based on determining that the network request has the characteristic, the system can forward the request to the service subsystem. The service subsystem can complete the network request using the service.

Abstract: Card controls can be selectively applied by a user to a card using a graphical user interface (GUI). The card controls can dictate whether network requests associated with usage of the card are to be handled using an account subsystem or a service subsystem. For example, the user can input a first selection to the GUI for applying a first card control in relation to a first type of network request. Based on the first selection, the system can be configured to complete network requests of the first type using the service subsystem. The user can also input a second selection to the GUI for applying a second card control in relation to a second type of network request. Based on the second selection, the system can be configured to complete network requests of the second type using the account subsystem.

Abstract: Card controls can be selectively applied by a user to a card using a graphical user interface (GUI). The card controls can dictate whether network requests associated with usage of the card are to be handled using an account subsystem or a service subsystem. For example, the user can input a first selection to the GUI for applying a first card control in relation to a first type of network request. Based on the first selection, the system can be configured to complete network requests of the first type using the service subsystem. The user can also input a second selection to the GUI for applying a second card control in relation to a second type of network request. Based on the second selection, the system can be configured to complete network requests of the second type using the account subsystem.

Abstract: Network requests can be automatically routed between two or more computer subsystems in some examples. In one such example, a system can determine that a user is eligible for a service based on usage data relating to an account of the user. Based on determining that the account is eligible for the service, the system can activate the service for the user by communicating with a service subsystem. Subsequent to activating the service for the user, the system can receive a network request associated with the user and determine that the network request has a characteristic. Based on determining that the network request has the characteristic, the system can forward the request to the service subsystem. The service subsystem can complete the network request using the service.

Abstract: Rules can be selectively applied by a user to an access card using a graphical user interface (GUI) of a mobile application. For example, the mobile application can provide a graphical user interface through which the user can select how usage of the access card is to be handled by the service provider. The mobile application can receive, through the graphical user interface, input from the user indicating one or more rules to be applied to the access card. The one or more rules can dictate how usage of the access card is to be handled by the service provider. In response to receiving the input, the mobile application can transmit one or more commands to a computer system associated with the service provider. The computer system can receive the one or more commands and implement the one or more rules selected by the user of the access card.

Abstract: Network requests can be automatically routed between two or more computer subsystems in some examples. In one such example, a system can determine that a user is eligible for a service based on usage data relating to an account of the user. Based on determining that the account is eligible for the service, the system can activate the service for the user by communicating with a service subsystem. Subsequent to activating the service for the user, the system can receive a network request associated with the user and determine that the network request has a characteristic. Based on determining that the network request has the characteristic, the system can forward the request to the service subsystem. The service subsystem can complete the network request using the service.

Abstract: Card controls can be selectively applied by a user to a card using a graphical user interface (GUI). The card controls can dictate whether network requests associated with usage of the card are to be handled using an account subsystem or a service subsystem. For example, the user can input a first selection to the GUI for applying a first card control in relation to a first type of network request. Based on the first selection, the system can be configured to complete network requests of the first type using the service subsystem. The user can also input a second selection to the GUI for applying a second card control in relation to a second type of network request. Based on the second selection, the system can be configured to complete network requests of the second type using the account subsystem.

Abstract: A method of and system for wirelessly transmitting a tip from a tipper to a tippee is disclosed. The method and system each eliminate the need for a tipper to make a cash payment to a service provider. The method and system employ a sound-based technique for transferring payment information from a tipper to a tippee. The method and system also enable the tippee to deposit the tip amount into an account that is configured such that the tip is automatically dispersed to a group of service providers according to a predetermined allocation schedule.

Abstract: A method of and system for wirelessly transmitting a tip from a tipper to a tippee is disclosed. The method and system each eliminate the need for a tipper to make a cash payment to a service provider. The method and system employ a sound-based technique for transferring payment information from a tipper to a tippee. The method and system also enable the tippee to deposit the tip amount into an account that is configured such that the tip is automatically dispersed to a group of service providers according to a predetermined allocation schedule.

Abstract: A computer-based method that includes specifying an arbitrary negative non-monetary utility that will be incurred by a beneficiary of insurance as a result of an uncertain occurrence to be covered by the insurance, using a computer to set a premium for insuring the specified arbitrary negative non-monetary utility, the premium being based on a probability of the occurrence and on the arbitrary utility, and making the arbitrary negative non-monetary utility an insurance benefit, and using a computer to manage the payment of the benefit.