Patent Application
20220101317
This disclosure is directed to systems and methods for creating and using secure payment authorization tokens.
Software as a Service (SaaS) is a software licensing and delivery model in which the software may be accessed or used on a subscription basis. The software may be located in a central location such as a cloud location and is accessible via a network.
As-a-Service subscription models are not limited to software. Hardware is also increasingly being made available in a similar manner. Succeeding updated versions of a hardware device may be made available to a subscriber as they are developed and replace previous versions.
This concept can be extended to making computing resources or services of a service provider available in a marketplace to users. Users can utilize the services in their applications. Users can subscribe to the services or can use them on a pay-as-you go basis. In such a scenario, an efficient accounting and payment process is also desirable.
The several features, objects, and advantages of exemplary embodiments will be understood by reading this description in conjunction with the drawings. The same reference numbers in different drawings identify the same or similar elements. In the drawings:
In the following description, numerous specific details are given to provide a thorough understanding of embodiments. The embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the exemplary embodiments.
Reference throughout this specification to an “example embodiment” or “example embodiments” means that a particular feature, structure, or characteristic as described is included in at least one embodiment. Thus, the appearances of these terms and similar phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. The headings provided herein are for convenience only and do not interpret the scope or meaning of the embodiments.
Software, hardware, or other technology may be provided to users as a service, whereby users subscribe to the service or can use them on a pay-as-you go basis. In such a scenario, an efficient accounting and payment process is desirable. Due to concerns with security, payments (as well as provisioning of services) in SaaS have to be processed in a secure and reliable manner.
This disclosure is directed providing novel methods and systems for facilitating such service availability and payment process in a secure and reliable manner. Example embodiments as disclosed provide for a payment authorization token that can be used to pay for computing services of a service provider utilized by a user or customer. The token may be encrypted and may include a combined plurality of encrypted data records.
In particular, a method for creating a payment token is disclosed. The method includes a service provider computer receiving a first data record from a customer computer. The first data record includes a first data buffer signed by a private key of the customer and having a public key of the customer associated therewith wherein the first data buffer includes a first set of parameters specified by the customer.
The service provider computer creates a second data buffer including a second set of parameters specified by the service provider. The second data buffer is signed with a first private key of the service provider. A first public key of the service provider is associated to the signed second data buffer to create a second data record. The first and second data records are combined to create a combined data record. The combined data record is signed with a second private key of the service provider. A second public key of the service provider is associated to the signed combined data record to create the payment token.
The secure payment authorization token may incorporate a set of parameters specified by or associated with a user/customer along with a set of parameters specified by or associated with a service provider. In the description, it is to be understood that, even if not stated specifically, the term “customer” may include a computer, a computer system or a computing associated with a customer. Similarly, the terms “service provider” may include a computer, a computer system or a computing system associated with a service provider.
A method 100 in accordance with an example embodiment is illustrated in
DB1 may then be signed with a private key associated with the customer (PRC) at 115 to create a first signed data buffer (SDB1). SDB1 may have a customer public key (PBC) associated therewith to create a first data record (DR1) at 120. DR1 may then be communicated to a computer system associated with a service provider at 125. The service provider may include a hardware processor-based computing system for managing accounting, metering, and/or other transactions associated with providing a service to the customer.
The service provider (computer system) may create a second data buffer (DB2) at 130. DB2 may include a second set of parameters. The second set of parameters may include a customer identification and a service provider specified promotion. The service provider specified promotion may include a specific number (e.g. a payment amount) or a percentage. The specific dollar amount or percentage of the promotion may reflect an amount of credit or discount that is applied to a customer's charges incurred for using services provided by the service provider.
The second set of parameters may also include an expiration date. The token including the parameters may be invalid beyond the expiration date. In some embodiments, the promotional credit or discount may no longer be applicable beyond the expiration date. The second set of parameters may also include a period of validity of the promotional credit or discount from the date of first use of the token. That is, the promotional credit or discount may expire after ten days from the date of first use of the token for example.
DB2 created by the service provider may be signed (by service provider computer system) with a first private key associated with the service provider (PRS1) to create a second signed data buffer (SDB2) at 135. A service provider's first public key (PBS1) may be associated with SDB2 to create a second data record (DR2) at 140.
The first and second data records (DR1 and DR2) may be combined to create a combined data record (CDR) at 145. CDR may be signed with a second private key of the service provider (PRS2) at 150 to create a signed combined data record (SCDR). A second public key of the service provider (PBS2) may be associated with SCDR to create the secure payment authorization token.
In some embodiments, promotional and expiration information described above, or portions thereof, may be included in the combined data record (CDR). That is, some information may be included in the data buffer and the remaining information may be included in the CDR.
The secure payment authorization token thus created may then be communicated to the computer system of a customer subscribing to or utilizing services provided by the service provider. In some embodiments, the payment token may be made available to the customer computer system upon invoking the service provider's services.
The method of creating a payment authorization token may also be described as a flow diagram in
Simultaneously, subsequently or previously, DB2230 created by a service provider computer system 225 may be signed by PRS1 to create SDB2235. SDB2 may be associated with PBS1 to create DR2240.
DR1120 and DR2240 may be combined by the service provider (computer system) 225 to create CDR 245. CDR may be signed by PRS2 to create SCDR 250. SCDR 250 may be associated with PBS2 to create a payment token 255.
The payment token created in accordance with method 100 of
PBS2 may be used to decrypt the token to extract CDR at 310. CDR may be separated into DR1 and DR2 at 315. As described above (with reference to
In some situations, the customer may wish to share payments for services utilized among different accounts. This may occur if multiple divisions, units or locations of the customer utilize the services provided by a service provider. The customer may desire to keep more accurate accounting records to apportion the expenses among the various sub-entities of the customer.
Embodiments of the present disclosure facilitate such apportionment. A method in accordance with such embodiments is illustrated in
A customer computer system (i.e. computing system of a customer subscribing to the services of a service provider such as one subscribing to a service provider) may create a first data buffer (DB1) at 410. DB1 may include a first set of parameters. The first set of parameters may include a customer identification (such as an account number) and a primary payment source information for customer. The payment source information can be a bank account number or a credit or debit card number.
DB1 may then be signed with a first private key of the customer (PRC1) to create a first signed data buffer (SDB1) at 415. A first public key of the customer (PBC1) may be associated with SDB1 to create a first data record (DR1) at 420.
The customer may then create a second data buffer (DB2) at 425. DB2 may include a second set of parameters. The second set of parameters may include a customer identification and a secondary or supplemental payment source information for the customer. The payment source information can be a bank account number or a credit or debit card number.
DB2 may be signed with a second private key of the customer (PRC2) to create a second signed data buffer (SDB2) at 430. A second public Key of the customer (PBC2) may be associated with SDB2 to create a second data record (DR2) at 435.
DR1 and DR2 may be communicated to a service provider computer system at 440. In the illustrated embodiment of
The service provider may combine DR1 and DR2 to create a combined data record (CDR) at 445. The combined data record may be signed with a private key of the service provider (PRS) to create a signed combined data record (SCDR) at 450. A public key of the service provider (PBS) may be associated with SCDR to create the secure payment authorization token at 455.
The secure payment authorization token thus created may then be communicated to a customer (computer system) subscribing to or utilizing services provided by the service provider.
In the method of
Such customer specified information can be included within the second set of parameters (i.e. second data buffer). In some embodiments, such information or portions thereof can be included within the combined data record (CDR). That is, some information may be included in the second data buffer and the remaining information may be included in the CDR.
In some example embodiments, since DB1 and DB2 are being encrypted by the customer (to create DR1 and DR2), they can be signed with the same private/public key pair.
Method of 400 of
DB2525 created by the customer may be signed with PRC2 to create SDB2530. PBC2 may be associated with SDB2 to create DR2535 that may be provided to the service provider computer system.
As described above with respect to
DR1520 and DR2535 may be combined by the service provider to create CDR 545. CDR 545 may be signed by PRS to create a SCDR 550. PBS may be associated with SCDR 550 to create a payment token 555.
The payment token created in accordance with method 400 of
PBS may be used to decrypt the token to extract CDR at 610. CDR may be separated into DR1 and DDR2 at 615. DR1 may be decrypted using PBC1 at 620. DR2 may be decrypted using PBC2 at 625. Parameters in each of DB1 and DB2 may be accessed at 630 and 635 respectively.
A customer may present the payment authorization token to a service provider for services utilized by the customer. The service provider may validate the token.
The token may be validated by determining whether the keys used to generate it (i.e. the token) are current. The public keys may be used to decrypt the token as described above to access the data parameters. The parameters include account identifying information.
In example embodiments, the service provider may maintain an account management service in which the public keys used are published. The public keys used for decryption may be checked against the published keys to determine a match. If the keys match, then the token can be utilized.
The payment authorization token can be revoked by either party (i.e. customer or service provider) at will. A replacement key can be published to the account management service to invalidate an old key for example. Any number of reasons can provide the basis for such a revocation. A key can be revoked/replaced for fear of it being compromised. It can be revoked if a service agreement between a customer and a service provider is terminated.
Upon the key being updated, any attempt to use an older payment authorization token will fail as the public keys used for the token will no longer match those published with the account management service.
If a customer chooses to invalidate their key, the consumer can generate a new public/private key pair and re-sign the data buffer of the payment authorization token with the new private key to form a working token for subsequent use without requiring additional action by a service provider other than to accept the newly published public key.
The generation of a new public/private key pair and re-signing of the data buffer of the payment authorization token may not preclude use of the old token if a customer still has a copy of the old key. In order to completely invalidate a key, the customer has to publish a replacement public key to the service provider's account management service for the customer account. Then, the old token cannot be used anymore because the customer public key in the token no longer matches the customer public key in the service.
For a limited time offer, a promotional data buffer may be signed with a private key created specifically for the promotion. When the promotion ends, the corresponding public key for the promotion can be deactivated (overwritten) in the account management service and tokens using the promotion will cease to work immediately.
A payment token created in accordance with the method of
DB2720 created by a service provider may be signed by PRS1 to create SDB2725. PBS1 may be associated with SDB2 to create DR2730.
DR2730 may be created by the service provider in response to receiving DR1715 from a customer. In some embodiments, DR2 may be created by the service provider prior to or, independent of, receiving DR1. In example embodiments, this would be done through a separate token generation service provided by the service provider.
DR1 and DR2 (715 and 730) may be combined by the service provider to create a CDR 735. CDR 735 may be signed by PRS2 to create SCDR 740. PBS2 SP may be associated with SCDR to create the payment token 745.
A payment token created in accordance with the method of
DB2820 created by the customer may be signed by PRC2 to create SDB2825. PBC2 may be associated with SDB2825 to create DR2830.
DR1 and DR2 (815 and 830) may be created by the customer either in dependence or independent of each other. The data records may be submitted to a service provider which combines the data records to create CDR 835. CDR 835 may be signed by PRS to create SCDR 840. PBS may be associated with SCDR to create payment token 845.
Service provider computer system 950 may include a transceiver 955, a processor 960, a non-transitory computer readable storage medium 965 and an input/output 970. Communication among each of these components may be facilitated by data bus 975.
The non-transitory computer readable storage media 925 and 965 may store instructions executable by the respective processors 920 and 960. In the example illustrated in
Memory 925 can include instructions for creating DB1, signing DB1 with PRC to create SDB1, associating PBC to SDB1 to create DR1 and for communicating DR1 to service provider computer system 950. PRC and PBC may also be stored in memory 925. DR1 may be transmitted via transceiver 915.
The transmitted DR1 may be received by service provider computer system 950 via transceiver 955. Memory 965 can include instructions for creating DB2, signing DB2 with PRS1 to create SDB2, associating PBS1 to SDB2 to create DR2, combining DR1 and DR2 to create CDR, signing CDR with PRS2 to create SCDR and associating PBS2 to SCDR to create the payment token.
PRS1, PBS1, PRS2 and PBS2 may be also be stored on memory 965. The token can be communicated to the customer computer system.
The respective computing devices associated with a customer and a service provider may communicate with each other over a network 940. The network can be a public network or a private network.
In other embodiments, the memory 925 and 965 may include instructions that can be executed by the respective processors 920 and 960 to implement the steps of the methods described herein with respect to
Encryption and decryption as specified above may utilize known techniques and therefore, are not described further. In some embodiments, the encryption may be asymmetric encryption. The keys issued may also have an expiration date or period of validity from date of first use.
A customer can generate multiple key pairs as needed or desired. A service provider can have multiple pairs of keys for a customer if the customer has multiple accounts with the service provider such as one for a particular project, a location or a division.
The pairs of keys (private/public) can be generated and assigned to (or associated with) a particular customer account by the service provider. Similarly, the customer can generate keys and assign (or associate) them to a particular service provider.
Example methods as described above for creating tokens can be performed by an automated, guided process. The user may be prompted to enter the first set of parameters by a computing device of the service provider while connected to the user computer. The interaction between the service provider and customer in creating the tokens can also be facilitated on a web browser interface.
While the present disclosure has been described in connection with certain example embodiments, it is to be understood that the disclosure is not limited to the disclosed embodiments, but, on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims, and equivalents thereof.
