Generation and distribution of named, definable, serialized tokens

A method for generating and distributing serialized tokens is provided. The method may include receiving a request from at least one client. The method may further include determining whether the received at least one request is a request for generating names and definitions for a group of serialized tokens, deleting a names and definitions, and/or receiving a group of serialized tokens. Additionally, the method may include enabling the at least one client to generate names and definitions for a group of serialized tokens. The method may also include storing the names and definitions on a server. The method may also include deleting the names and definitions from the server. The method may also include formatting and distributing serialized tokens based on the names and definitions for the serialized tokens. The method may further include sending a response to the client based on the received request.

BACKGROUND

The present invention relates generally to the field of computing, and more specifically, to serialized tokens.

Generally, in application and software development, tokens may be generated to enable such actions as communication between servers and clients. Typically, tokens are generated based on a specific format and are unique. Serialized tokens are tokens that are typically generated incrementally, or in a series, based on a specific format. Furthermore, the generation of serialized and unique tokens often occurs in a dynamic environment, with multiple concurrent client tasks demanding serialized and unique tokens simultaneously. A common process to client demands of serialized tokens is to use servers to format and generate the serialized tokens and incrementally distribute the serialized tokens as requested by clients so that no two tasks are provided the same serialized token. For example, servers may define the format of the serialized tokens and distribute the tokens incrementally, such as Log-001, Log-002, and Log-003 . . . , to clients as the clients request the tokens to perform software tasks.

SUMMARY

A method for generating and distributing a plurality of serialized tokens is provided. The method may include receiving at least one request from at least one client. The method may include receiving at least one request from at least one client. The method may further include receiving at least one request from at least one client. The method may also include determining whether the received at least one request is a request for generating at least one name and at least one definition for a group of serialized tokens. The method may further include, in response to the determination that the received at least one request is a request for generating the at least one name and the at least one definition for the group of serialized tokens, enabling the at least one client to generate the at least one name and the at least one definition for the group of serialized tokens. Additionally, the method may include storing the generated at least one name and the generated at least one definition on at least one server. The method may also include determining whether the received at least one request is a request for deleting at least one second name and at least one second definition for a second group of serialized tokens. The method may further include, in response to the determination that the received at least one request is a request to delete the at least one second name and the at least one second definition for the second group of serialized tokens, deleting the at least one second name and the at least one second definition for the second group of serialized tokens from the at least one server. The method may also include determining whether the received at least one request is a request for receiving the second group of serialized tokens based on the at least one second name and the at least one second definition. The method may further include, in response to the determination that the received at least one request is a request for receiving the second group of serialized tokens, formatting and distributing the second group of serialized tokens based on the at least one second name and the at least one second definition. The method may also include sending a response to the client based on the received at least one request.

A computer system for generating and distributing a plurality serialized tokens is provided. The computer system may include one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage devices, and program instructions stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, whereby the computer system is capable of performing a method. The method may include receiving at least one request from at least one client. The method may also include determining whether the received at least one request is a request for generating at least one name and at least one definition for a group of serialized tokens. The method may further include, in response to the determination that the received at least one request is a request for generating the at least one name and the at least one definition for the group of serialized tokens, enabling the at least one client to generate the at least one name and the at least one definition for the group of serialized tokens. Additionally, the method may include storing the generated at least one name and the generated at least one definition on at least one server. The method may also include determining whether the received at least one request is a request for deleting at least one second name and at least one second definition for a second group of serialized tokens. The method may further include, in response to the determination that the received at least one request is a request to delete the at least one second name and the at least one second definition for the second group of serialized tokens, deleting the at least one second name and the at least one second definition for the second group of serialized tokens from the at least one server. The method may also include determining whether the received at least one request is a request for receiving the second group of serialized tokens based on the at least one second name and the at least one second definition. The method may further include, in response to the determination that the received at least one request is a request for receiving the second group of serialized tokens, formatting and distributing the second group of serialized tokens based on the at least one second name and the at least one second definition. The method may also include sending a response to the client based on the received at least one request.

A computer program product for enabling at least one user interface display field to perform at least one action is provided. The computer program product may include one or more computer-readable storage devices and program instructions stored on at least one of the one or more tangible storage devices, the program instructions executable by a processor. The computer program product may include program instructions to receive at least one request from at least one client. The computer program product may also include program instructions to determine whether the received at least one request is a request for generating at least one name and at least one definition for a group of serialized tokens. The computer program product may further include, in response to the determination that the received at least one request is a request for generating the at least one name and the at least one definition for the group of serialized tokens, program instructions to enable the at least one client to generate the at least one name and the at least one definition for the group of serialized tokens. Additionally, the computer program product may include program instructions to store the generated at least one name and the generated at least one definition on at least one server. The computer program product may also include program instructions to determine whether the received at least one request is a request for deleting at least one second name and at least one second definition for a second group of serialized tokens. The computer program product may further include, in response to the determination that the received at least one request is a request to delete the at least one second name and the at least one second definition for the second group of serialized tokens, program instructions to delete the at least one second name and the at least one second definition for the second group of serialized tokens from the at least one server. The computer program product may also include program instructions to determine whether the received at least one request is a request for receiving the second group of serialized tokens based on the at least one second name and the at least one second definition. The computer program product may further include, in response to the determination that the received at least one request is a request for receiving the second group of serialized tokens, program instructions to format and distribute the second group of serialized tokens based on the at least one second name and the at least one second definition. The computer program product may further include program instructions to send a response to the client based on the received at least one request.

DETAILED DESCRIPTION

Embodiments of the present invention relate generally to the field of computing, and more particularly, to serialized tokens. The following described exemplary embodiments provide a system, method and program product for generating and distributing serialized tokens. Therefore, the present embodiment has the capacity to improve the technical field associated with serialized tokens by enabling clients to name and define serialized tokens. Specifically, the present embodiment may enable clients, instead of servers, to name and define the format for serialized tokens, store the named and defined format for the serialized tokens on servers, and request distribution of the named and defined serialized tokens on demand based on the format definitions.

As previously described with respect to serialized tokens, servers commonly dictate set formats for generating serialized tokens and incrementally distributing the serialized tokens at clients' requests. However, having servers dictate the generation and distribution of serialized tokens is limiting. Certain aspects, such as the life-cycle of the serialized token, may be controlled by the server. Furthermore, applications may have code for token generation and supply, which means that the same sort of code may be written over and over. However, the required format generated by the server may be different. As such, it may be advantageous, among other things, to provide a system, method and program product for enabling client-side devices to generate and control distribution of serialized tokens. Specifically, the system, method and program product may enable clients to name formats associated with serialized tokens so that the number of potential formats is only limited by the possible number of names, control the format of the serialized tokens consumed by the clients, control the life-cycle of serialized tokens, and create different formats for serialized tokens.

According to at least one implementation of the present embodiment, requests for serialized tokens may be received. Next, whether the received requests are for creating names and definitions for serialized tokens may be determined. Then, if the received requests are for creating names and definitions for serialized tokens, the clients may create the names and definitions for serialized tokens and store the names and definitions on server databases. Next, if the received requests are not for creating names and definitions for serialized tokens, whether the received requests are for deleting names and definitions for serialized tokens may be determined. Then, if the received requests are for deleting the names and definitions for serializes tokens, the stored names and definitions for serialized tokens on the server databases may be deleted. Next, if the received requests are not for deleting the names and definitions for serialized tokens, whether the received requests are for requesting serialized tokens based on the names and definitions may be determined. Then, if the received requests are for requesting serialized tokens based on the names and definitions, the stored names may be read and the serialized tokens may be formatted and retrieved based on the stored definitions. Next, replies may be sent according to the performed action.

The following described exemplary embodiments provide a system, method and program product for generating and distributing serialized tokens.

According to at least one implementation, requests for serialized tokens may be received. Next, whether the received requests are for creating names and definitions for serialized tokens may be determined. Then, if the received requests are for creating names and definitions for serialized tokens, the clients may create the names and definitions for serialized tokens and store the names and definitions on server databases. Next, if the received requests are not for creating names and definitions for serialized tokens, whether the received requests are for deleting names and definitions for serialized tokens may be determined. Then, if the received requests are for deleting the names and definitions for serializes tokens, the stored names and definitions for serialized tokens on the server databases may be deleted. Next, if the received requests are not for deleting the names and definitions for serialized tokens, whether the received requests are for requesting serialized tokens based on the names and definitions may be determined. Then, if the received requests are for requesting serialized tokens based on the names and definitions, the stored names may be read and the serialized tokens may be formatted and retrieved based on the stored definitions. Next, replies may be sent according to the performed action.

Referring now toFIG. 1, an exemplary networked computer environment100in accordance with one embodiment is depicted. The networked computer environment100may include a computer102with a processor104and a data storage device106that is enabled to run a token generation and distribution program108A and a software program114. The software program114may be an application program such as an internet browser and an email program. The token generation and distribution program108A may communicate with the software program114. The networked computer environment100may also include a server112that is enabled to run a token generation and distribution program108B and a communication network110. The networked computer environment100may include a plurality of computers102and servers112, only one of which is shown for illustrative brevity.

According to at least one implementation, the present embodiment may also include a database116, which may be running on server112. The communication network110may include various types of communication networks, such as a wide area network (WAN), local area network (LAN), a telecommunication network, a wireless network, a public switched network and/or a satellite network. It may be appreciated thatFIG. 1provides only an illustration of one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environments may be made based on design and implementation requirements.

The client computer102may communicate with server computer112via the communications network110. The communications network110may include connections, such as wire, wireless communication links, or fiber optic cables. As will be discussed with reference toFIG. 3, server computer112may include internal components800aand external components900a, respectively and client computer102may include internal components800band external components900b, respectively. Server computer112may also operate in a cloud computing service model, such as Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS). Server112may also be located in a cloud computing deployment model, such as a private cloud, community cloud, public cloud, or hybrid cloud. Client computer102may be, for example, a mobile device, a telephone, a personal digital assistant, a netbook, a laptop computer, a tablet computer, a desktop computer, or any type of computing device capable of running a program and accessing a network. According to various implementations of the present embodiment, the token generation and distribution program108A,108B may interact with a database116that may be embedded in various storage devices, such as, but not limited to a mobile device102, a networked server112, or a cloud storage service.

According to the present embodiment, a program, such as a token generation and distribution program108A and108B may run on the client computer102or on the server computer112via a communications network110. The token generation and distribution program108A,108B may enable clients to control the generation and formatting of serialized tokens. Specifically, a user using a computer, such as computer102, may run a token generation and distribution program108A,108B, that interacts with a software program114, such as a web browser, to enable clients to create serialized tokens by naming and defining serialized tokens, and storing the created names and definitions associated with the serialized tokens on servers for retrieval at client requests.

Referring now toFIG. 2, an operational flowchart200illustrating the steps carried out by a program for generating and distributing serialized tokens is depicted. At202, the token generation and distribution program108A,108B (FIG. 1) may receive client requests. Specifically, the token generation and distribution program108A,108B (FIG. 1) may receive client requests to create names and definitions for serialized tokens, delete the names and definitions associated with serialized tokens, and/or receive named and defined serialized tokens. For example, the token generation and distribution program108A,108B (FIG. 1) may receive HTTP RESTful API requests from client applications to name and define serialized tokens.

Next, at204, the token generation and distribution program108A,108B (FIG. 1) may determine whether the received requests are for creating names and definitions for serialized tokens. As previously described at step202, the token generation and distribution program108A,108B (FIG. 1) may receive client requests to create names and definitions for serialized tokens. For example, the token generation and distribution program108A,108B (FIG. 1) may receive HTTP RESTful API requests from a client application to create names and definitions for serialized tokens associated with the world wide web. Therefore, the token generation and distribution program108A,108B (FIG. 1) may determine that the received requests are to create names and definitions for serialized tokens.

Then, at206, the token generation and distribution program108A,108B (FIG. 1) may enable clients to create the names and definitions for the serialized tokens. Specifically, according to one embodiment, the token generation and distribution program108A,108B (FIG. 1) may receive the format for distributing serialized tokens by enabling clients to create names and definitions for serialized tokens. For example, the token generation and distribution program108A,108B (FIG. 1) may receive names and definitions for serialized tokens via JavaScript Object Notation (JSON) data and/or Extensive Markup Language (XML) data. Furthermore, the token generation and distribution program108A,108B (FIG. 1) may enable users to create names for serialized tokens, such as naming the serialized tokens as MY_SERIALIZED_TOKENS, and may enable users to create definitions for the name MY_SERIALIZED_TOKENS, such as defining MY_SERIALIZED_TOKENS as LITERAL-AA-0000 to LITERAL ZZ-9999, where 0000-9999 is a first counter and AA-ZZ is a second counter, and the first counter and the second counter determine the order of distribution for the serialized tokens. Thus, according to the previous example, the token generation and distribution program108A,108B (FIG. 1) may distribute the serialized tokens based on the created definition by incrementing the first counter 0000-9999 in the order defined by users, then incrementing the second counter AA-ZZ in the order defined by users.

For example, the token generation and distribution program108A,108B (FIG. 1) may increment the first counter 0000-9999 by 1 up to 9999 (i.e. 0001, 0002, 0003 . . . NNNN), then increment the second counter AA by 1 up to ZZ (i.e. AA, AB, AC . . . ). Therefore, the token generation and distribution program108A,108B (FIG. 1) may determine that the first counter 0000-9999 has a min value of 0000 and a max value of 9999, and that the second counter has a min value of 0 and a max value of 675 (i.e. based on 26 letters in the alphabet, calculated as 26*26−1). Furthermore, the token generation and distribution program108A,108B (FIG. 1) may determine that the number of counting positions used by the first counter 0000-9999 is 4 (i.e. 4 numbers are used by the first counter to increment by 1) and the number of counting positions used by the second counter AA-ZZ is 2 (i.e. 2 letters are used by the second counter to increment by 1). Additionally, the token generation and distribution program108A,108B (FIG. 1) may determine that the symbols used for the first counter are 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, and that the symbols used by the second counter are A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z. Thus, according to the previous example, the token generation and distribution program108A,108B (FIG. 1) may enable users to generate pseudocode for creating names and definitions for serialized tokens, such as:

Also, according to one embodiment, the token generation and distribution program108A,108B (FIG. 1) may enable users to create non-numeric definitions for serialized tokens. For example, the token generation and distribution program108A,108B (FIG. 1) may enable users to name serialized tokens as BEATLES, and may enable users to create definitions for the serialized tokens BEATLES by using 4 unique IDs, such as JOHN, PAUL, GEORGE, RINGO. Furthermore, the token generation and distribution program108A,108B (FIG. 1) may enable users to increment BEATLES by 1 from JOHN to RINGO in the order of JOHN, PAUL, GEORGE, RINGO. Therefore, according to the previous example, the token generation and distribution program108A,108B (FIG. 1) may enable users to generate pseudocode for naming and defining the non-numeric serialized tokens such as:

Then, at208, the token generation and distribution program108A,108B (FIG. 1) may store the created names and definitions for serialized tokens on server databases. As previously described at step204, the token generation and distribution program108A,108B (FIG. 1) may determine whether the received requests are for creating names and definitions for serialized tokens, and if so, the token generation and distribution program108A,108B (FIG. 1) may enable users to create the names and definitions for the serialized tokens at step206. For example, and as previously described at step204, the token generation and distribution program108A,108B (FIG. 1) may enable users to create MY_SERIALIZED_TOKENS, and may enable users to define MY_SERIALIZED_TOKENS as LITERAL-AA-0000 to LITERAL ZZ-9999. As such, the token generation and distribution program108A,108B (FIG. 1) may receive the created names and definitions for serialized tokens, then may store the received names and definitions for serialized tokens on server databases for retrieval at clients' requests.

Next, at210, the token generation and distribution program108A,108B (FIG. 1) may determine whether the received client requests are to delete the names and definitions associated with the serialized tokens. Specifically, if the token generation and distribution program108A,108B (FIG. 1) determines that the received clients requests are not for creating names and definitions for serialized tokens at step204, the token generation and distribution program108A,108B (FIG. 1) may determine whether the client requests are for deleting the names and definitions associated with serialized tokens. For example, the token generation and distribution program108A,108B (FIG. 1) may have enabled users to create names and definitions for the serialized tokens named BEATLES. Then, the token generation and distribution program108A,108B (FIG. 1) may receive a client request to delete the serialized tokens associated with the name BEATLES.

Then, at212, the token generation and distribution program108A,108B (FIG. 1) may delete the names and definitions associated with the serialized tokens from the server databases. As previously described at step208, the token generation and distribution program108A,108B (FIG. 1) may store names and definitions associated with serialized tokens on server databases. For example, the token generation and distribution program108A,108B (FIG. 1) may have stored the names and definitions associated with the serialized tokens named MY_SERIALIZED_TOKENS. Then, as previously described at step210, the token generation and distribution program108A,108B (FIG. 1) may determine that a received client request, such as HTTP DELETE MY_SERIALIZED_TOKEN, is a request for the server to delete the stored name and definition associated with the serialized tokens named MY_SERIALIZED_TOKENS. Therefore, the token generation and distribution program108A,108B (FIG. 1) may delete the stored name MY_SERIALIZED_TOKENS and the definitions associated with the stored name MY_SERIALIZED_TOKENS from the server databases.

Next, at214, the token generation and distribution program108A,108B (FIG. 1) may determine whether the received client requests are requests to receive serialized tokens. Specifically, if the token generation and distribution program108A,108B (FIG. 1) determines that the received clients requests are not for generating named and defined serialized tokens at step204, and not for deleting the named and defined serialized tokens at step210, the token generation and distribution program108A,108B (FIG. 1) may determine whether the received clients requests are requests to receive serialized tokens based on the names and definitions. As previously described at step208, the token generation and distribution program108A,108B (FIG. 1) may store the names and definitions associated with serialized tokens. As such, the token generation and distribution program108A,108B (FIG. 1) may enable clients to use serialized tokens by receiving requests to receive serialized tokens based on the names and definitions. For example, the token generation and distribution program108A,108B (FIG. 1) may store the names and definitions for serialized tokens, such as the name MY_SERIALIZED_TOKENS, and the definition LITERAL-AA-0000 to LITERAL ZZ-9999. Then, at step214, the token generation and distribution program108A,108B (FIG. 1) may determine that the received client request, such as HTTP GET MY_SERIALIZED_TOKEN, is a request to receive serialized tokens based on the name MY_SERIALIZED_TOKENS and the definition LITERAL-AA-0000 to LITERAL ZZ-9999.

As such, at step216, the token generation and distribution program108A,108B (FIG. 1) may read the stored name and definition from the server databases. Thus, according to the previous example, based on the received client request, the token generation and distribution program108A,108B (FIG. 1) may read the stored definition name MY_SERIALIZED_TOKENS.

Then, at step218, the token generation and distribution program108A,108B (FIG. 1) may format and distribute the requested serialized tokens according to the stored name and definition. Specifically, the token generation and distribution program108A,108B (FIG. 1) may format and distribute serialized tokens to the requesting clients based on the created names and definitions. Therefore, based on the previous example, the token generation and distribution program108A,108B (FIG. 1) may read the stored name MY_SERIALIZED_TOKENS, then may format and distribute MY_SERIALIZED_TOKENS based on the definition LITERAL-AA-0000 to LITERAL ZZ-9999.

For example, the token generation and distribution program108A,108B (FIG. 1) may determine that the client requests the next 3 serialized tokens associated with the created name MY_SERIALIZED_TOKENS. Furthermore, the token generation and distribution program108A,108B (FIG. 1) may determine that the next 3 serialized tokens associated with the created name MY_SERIALIZED_TOKENS, and distributed based on the definition LITERAL-AA-0000 to LITERAL ZZ-999, are LITERAL-AA-0056, LITERAL-AA-0057, and LITERAL-AA-0058. Therefore, the token generation and distribution program108A,108B (FIG. 1) may format the serialized tokens based on the created name and definition by receiving the determined next 3 serialized tokens associated with MY_SERIALIZED_TOKENS, as well as bookmarking the counting position of the first counter and the second counter (i.e. determining where the counter left off, which, for this example, is at LITERAL-AA-0059).

Then, at220, the token generation and distribution program108A,108B (FIG. 1) may send responses based on the received client requests. Specifically, the token generation and distribution program108A,108B (FIG. 1) may send responses based on the determinations made at steps204,210, and214. For example, as previously described at step204, the token generation and distribution program108A,108B (FIG. 1) may receive requests for creating names and definitions for serialized tokens, may enable clients to create the names and definitions, and may store the created names and definitions on server databases at step208. Therefore, the token generation and distribution program108A,108B (FIG. 1) may send a response indicating that the user's names and definitions for serialized tokens are generated and stored. Also, for example, and as previously described at step210, the token generation and distribution program108A,108B (FIG. 1) may receive client requests to delete created names and definitions for serialized tokens, and may delete the names and definitions for serialized tokens at step212. Therefore, the token generation and distribution program108A,108B (FIG. 1) may send a response indicating that the created names and definitions for serialized token are deleted. Furthermore, for example, and as previously described at step214, the token generation and distribution program108A,108B (FIG. 1) may receive client requests to receive serialized tokens based on created names and definitions. Therefore, the token generation and distribution program108A,108B (FIG. 1) may send a response that may include the requested serialized tokens according to the created name and definition.

It may be appreciated thatFIG. 2provide only illustrations of one implementation and does not imply any limitations with regard to how different embodiments may be implemented. Many modifications to the depicted environments may be made based on design and implementation requirements. According to one embodiment, in step220, the token generation and distribution program108A,108B (FIG. 1) may send error messages as responses to users. For example, the token generation and distribution program108A,108B (FIG. 1) may receive client requests to receive serialized tokens named MY_SERIALIZED_TOKENS. However, MY_SERIALIZED_TOKENS may not have remaining serialized tokens. Also, for example, the token generation and distribution program108A,108B (FIG. 1) may receive a request for creating serialized tokens named MY_SERIALIZED_TOKENS. However, the name MY_SERIALIZED_TOKENS may already be in use. Thus, in the first example, the token generation and distribution program108A,108B (FIG. 1) may send an error message as a response indicating that there are no more serialized tokens according to the definition associated with the name MY_SERIALIZED_TOKENS. Furthermore, in the second example, the token generation and distribution program108A,108B (FIG. 1) may send an error message as a response indicating that the name MY_SERIALIZED_TOKENS is already in use.

User client computer102(FIG. 1), and network server112(FIG. 1) include respective sets of internal components800a, band external components900a, billustrated inFIG. 3. Each of the sets of internal components800a, bincludes one or more processors820, one or more computer-readable RAMs822and one or more computer-readable ROMs824on one or more buses826, and one or more operating systems828and one or more computer-readable tangible storage devices830. The one or more operating systems828, the software program114(FIG. 1), the token generation and distribution program108A (FIG. 1) in client computer102(FIG. 1), and the token generation and distribution program108B (FIG. 1) in network server computer112(FIG. 1) are stored on one or more of the respective computer-readable tangible storage devices830for execution by one or more of the respective processors820via one or more of the respective RAMs822(which typically include cache memory). In the embodiment illustrated inFIG. 3, each of the computer-readable tangible storage devices830is a magnetic disk storage device of an internal hard drive. Alternatively, each of the computer-readable tangible storage devices830is a semiconductor storage device such as ROM824, EPROM, flash memory or any other computer-readable tangible storage device that can store a computer program and digital information.

Each set of internal components800a, b, also includes a R/W drive or interface832to read from and write to one or more portable computer-readable tangible storage devices936such as a CD-ROM, DVD, memory stick, magnetic tape, magnetic disk, optical disk or semiconductor storage device. A software program, such as a token generation and distribution program108A and108B (FIG. 1), can be stored on one or more of the respective portable computer-readable tangible storage devices936, read via the respective R/W drive or interface832and loaded into the respective hard drive830.

Each set of internal components800a, balso includes network adapters or interfaces836such as a TCP/IP adapter cards, wireless Wi-Fi interface cards, or 3G or 4G wireless interface cards or other wired or wireless communication links. The token generation and distribution program108A (FIG. 1) and software program114(FIG. 1) in client computer102(FIG. 1), and the token generation and distribution program108B (FIG. 1) in network server112(FIG. 1) can be downloaded to client computer102(FIG. 1) from an external computer via a network (for example, the Internet, a local area network or other, wide area network) and respective network adapters or interfaces836. From the network adapters or interfaces836, the token generation and distribution program108A (FIG. 1) and software program114(FIG. 1) in client computer102(FIG. 1) and the token generation and distribution program108B (FIG. 1) in network server computer112(FIG. 1) are loaded into the respective hard drive830. The network may comprise copper wires, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers.

Each of the sets of external components900a, bcan include a computer display monitor920, a keyboard930, and a computer mouse934. External components900a, bcan also include touch screens, virtual keyboards, touch pads, pointing devices, and other human interface devices. Each of the sets of internal components800a, balso includes device drivers840to interface to computer display monitor920, keyboard930, and computer mouse934. The device drivers840, R/W drive or interface832and network adapter or interface836comprise hardware and software (stored in storage device830and/or ROM824).

Characteristics are as Follows:

Service Models are as Follows:

Deployment Models are as Follows:

Referring now toFIG. 4, illustrative cloud computing environment400is depicted. As shown, cloud computing environment400comprises one or more cloud computing nodes100with which local computing devices used by cloud consumers, such as, for example, personal digital assistant (PDA) or cellular telephone400A, desktop computer400B, laptop computer400C, and/or automobile computer system400N may communicate. Nodes100may communicate with one another. They may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment400to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of computing devices400A-N shown inFIG. 4are intended to be illustrative only and that computing nodes100and cloud computing environment400can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Workloads layer90provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include: mapping and navigation91; software development and lifecycle management92; virtual classroom education delivery93; data analytics processing94; transaction processing95; and Token Generation and Distribution96. A Token Generation and Distribution Program108A,108B (FIG. 1) may be offered “as a service in the cloud” (i.e., Software as a Service (SaaS)) for applications running on mobile devices102(FIG. 1) and may generate and distribute serialized tokens based on client input.