Data Server with Transit Containers for Resource Movements

Data processing systems may comprise one or more computing devices that are connected over a wired and/or wireless communication medium. The medium may include any combination of wired transmission channels (e.g., fiber optic or traditional wire cables) and wireless channels (e.g., electromagnetic transmissions over frequency). This wired or wireless medium, the communication protocols used by the various computing devices, and intermediate devices between endpoints, may be referred to as a computer network. A data processing systems may act as a server which determines, retains, and transmits data electronically over the computer network to a client. A server may have a variety of real-world applications which may interact with other servers, or serve as an endpoint that interacts with human users. These applications are numerous in type and scope, and may include operations related to controlling machinery, transportation, detecting weather, telecommunications, cellular networks, maintaining records, artificial intelligence, facilitating transactions, and more.

Data processing systems may be connected over the computer network for transmitting and sharing information. Each data processing system may perform one or more dedicated services. Computing devices connected to a computer network may include mobile devices, machinery, industrial equipment, household equipment, medical equipment, home computers, web servers, file servers, and more. A computer network may include network-specific devices such as routers, switches, firewalls, and more.

Data processing systems may be connected to a computer network, and interact with one or more clients to support movement of physical resources (e.g., oil, coal, gasoline, grain, metal, lumber, etc.) or digital resources (e.g., credits, funds, etc.) from a source to a destination. The source and/or destination may be associated with same client or different clients. Data processing systems may facilitate numerous complex movements of resources for different clients in real-time (e.g., with minimal delay as the request is received from the client). In some cases, multiple resource movements may be grouped together due to a common purpose or scenario, further complicating the operation. It is desirable to support these resource movements with an efficient use of compute resources while ensuring correctness of these resource movements, being extensible, and being flexible in supporting a variety of different use cases by different potential clients.

In the following description, numerous details are set forth. It will be apparent, however, to one of ordinary skill in the art having the benefit of this disclosure, that the embodiments described herein may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the embodiments described herein.

Some portions of the detailed description that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “receiving”, “determining”, “storing”, “detecting”, “applying”, “transmitting”, “moving”, “transitioning”, “configuring”, “transmitting”, “releasing”, “transitioning”, or the like, refer to the actions and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. Operations said to be performed automatically may refer to operations being performed based on logic or an algorithm executed by a computing device, without human input at the time of the operation or decision.

The embodiments discussed herein may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the embodiments discussed herein are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings as described herein.

As described, movement of resources may be complex when there are multiple requests to move resources, and each request may invoke multiple movements across different sources and different destinations at different times. A computer data server may need to compose multiple single-leg resource movement instructions to model a desired behavior. While existing systems can achieve this using non-standardized intermediate containers, the resources in these containers tend to be fungible and not protected for an intended use. For example, asynchronous resource flows, such as revocations and refunds, can claim a resource from the intermediate containers used by complex resource flow scenarios, but because these intermediate containers do not treat the resources as non-fungible, the complexity of the different resource movements among many different requests may lead to intermingling of resources. Further, such systems may lack an efficient mechanism to reclaim memory used by these intermediate containers. Further, such systems may lack a well-defined state-based container to store resources, and well defined API calls that interact with these states to ensure correct flow of resources to or from the containers.

Aspects described may be performed by a distributed computing platform that comprises a plurality of services (e.g., microservices), each being independently runnable, independently buildable, and independently deployable, thereby providing extensibility and flexibility in supporting resource movements. Additional application-level or user-facing logic may be built into secondary services while a dedicated service manages a state-based transit container, as disclosed in the present disclosure.

Aspects described comprise a computer data server comprising services (and teams dedicated to building these services) that support simple and reliable earmarked resources for dedicated use within compound resource flow scenarios. A state-based transit container has states that supports calls from other services (e.g., products) of the computer data server. These calls are made to perform a resource movement that specifies the source or destination in any resource movement instruction, and are linked together using a transit group ID that the transit container is associated with. The transit group ID is used as access control to the transit container. Use of such a transit container, with a predefined set of API calls that limit flows of resources into and out of the transit container, provides built-in auditability that ensures that complex, multi-source, multi-destination flows of resources can be reliably delivered to the intended destinations without those resources being inadvertently being diverted or intermingled with other resources.

Aspects of the present disclosure may mitigate these issues by segregating earmarked resources in between individual resource flow operations and enforcing that only the intended operations can access those resources. Aspects of the disclosed computer data server may track and record every single resource flow that operates on the reserved resources, and ensure that all resources that are reserved in a transit container are eventually fully disbursed out to destinations such as other containers internal to the system, or external containers (e.g., an external container managed by a client device or database). Services within the computer data server can operate on the resources with reduced risk that the resources may be accidentally taken by another service, resulting in misuse of resources or balances of the resource inadvertently going negative.

In one aspect, a server computing system, includes a plurality of services, where a first service of the plurality of services is configured to perform operations including: in response to receiving a first API call, generating a transit container in memory that is associated with a transit group ID. In response to receiving a second API call with the transit group ID to move a resource into the transit container, the first service moves the resource to the transit container with a state of the transit container being an inbound pending held state. The first service then transitions the state of the transit container to a resource held state, in response to the resource being deemed to be received. The first service is configured to access the resource of the transit container in the resource held state in response to one or more additional API calls that comprise the transit group ID, and release the transit container for garbage collection in response to when a condition of the transit container is satisfied.

In an embodiment, the first service is further to: in response to receiving a third API call includes the transit group ID when the transit container has the resource held state, move an amount of the resource from the resource held state of the transit container and into a destination specified by the third API call. In an embodiment, the second API call moves the resource into the transit container from a resource state of the transit container. In an embodiment, in response to receiving the third API call when the transit container is in an inbound pending state or the inbound pending held state, the first service rejects the third API call.

In an embodiment, one of the plurality of services receives an external request from an external client over a computer network to move the resource to one or more destinations, and the first API call is transmitted to the first service in response to the external request.

In an embodiment, in response to receiving a third API call with the transit group ID from one of the plurality of services, the first service moves a portion of the resource from the transit container under the inbound pending held state to the transit container under the resource held state. In response to receiving a fourth API call with the transit group ID from one of the plurality of services, the first service moves a first specified portion of the resource from the transit container under the resource held state to a specified second container. In response to receiving a fifth API call with the transit group ID from one of the plurality of services, the first services moves a second specified portion of the resource to a specified third container. In such a manner, the transit container along with the transit group ID and the API calls may support a desired set of related movements of a resource.

In an embodiment, the service may further generate, with one of the plurality of services, a user facing container, map an inbound pending state of the user facing container to aggregated resources associated with inbound pending state, and transmit, to another service or to a client, the inbound pending state of the user facing container.

In an embodiment, in response to receiving a third API call from one of the plurality of services to move additional resources to the transit container, the first service moves the additional resources to the transit container with the state of the transit container being the resource held state. In response to receiving a fourth API call from one of the plurality of services, the first service transfers the resource of the transit container with the state of the transit container being the resource held state to a final one of the one or more destinations.

Transit containers also enable the overall system to capture a history of resource movements, which may satisfy regulations that complex resource movements are sufficiently locked down and cannot be used for purposes that go against required regulatory restrictions. More generally, these transit containers may support contractual or purely operational constraints associated with a movement of resources. Although the services still manage the orchestration of compound and complex resource flows, the state-based structure of transit containers and enforcement of particular workflows, as they are implemented and enforced through structured API calls, provide guardrails against intermingling, and a trail that enables services to determine whether compound resource flows have successfully cleared all resources to their intended destinations, in addition to other advantages described in other sections.

1 FIG. 116 118 118 120 118 116 illustrates an example of a server computing system with a transit container feature, in accordance with an embodiment. Server computing systemmay comprise a plurality of services. Each of the plurality of servicesmay be independently buildable, runnable, and deployable. Each may comprise a dedicated set of compute resources (e.g., memory, processor resources, etc.). The servicesmay communicate with each other over a dedicated backplane (e.g., over a computer network) and may request operations of each other through well-defined API calls with agreed upon parameters and behavior. In an embodiment, the server computing systemmay comprise a cluster, e.g., a group of interconnected computers or servers that work together as a single system.

118 116 112 116 104 114 114 Generally, one or more servicesof the server computing systemmay work together to provide a desired and encapsulated functionality to a client, and this functionality may be referred to as a product. In an example, server computing systemcreates a transit containeron a per product, per client (e.g., a manufacturer, a warehouse, a merchant, a shipper, etc.), and product use case. This is done either when the client enables the product (e.g., through a network-based request), or when the client uses a transit container for the first time (e.g., also through the network-based request).

124 118 104 118 124 104 124 104 120 106 120 104 102 A first serviceof the plurality of servicesis configured to perform operations related to transit container. For example, another one of the servicesmay transmit a first API call to the first service. This first API call may be a request to generate a new transit container. In response to receiving the first API call, the first servicegenerates transit containerin memorythat is associated with a transit group ID. Memorymay represent short-term memory (e.g., random access memory), long-term memory (e.g., disk memory, solid state long-term memory, etc.), or a combination thereof. For example, transit containermay be stored in a database (e.g., databaseor a different database), or in other long-term memory.

104 104 124 104 106 110 104 106 104 Generally, transit containers such as transit containermay be a subtype of non-transit containers. Each transit containermay act as source and/or destination of different resource flows. Each transit container may provide per-compound-resource movement clearing abilities. First servicelimits access to transit containerby enforcing state-based rules and based on transit group ID. An API call to move a resourceinto, within, or out of the transit containermust include the correct transit group IDthat the transit containerwas created with.

104 110 104 104 124 104 118 118 Each transit containerprovides a single request-based non-fungibility and debit-safety from unrelated resource flows and even instances of the same resource flow. Transit containers are generally created in the process of initiating a resource movement. Transit containers hold a balance or amount of a resource, and are always clearing: when all the resource movements touching a transit containerare complete, the transit containermust have a balance of zero. To achieve this, first serviceperforms a per-compound-resource movement tracking of inflows and outflows to a transit container, to provide clearing abilities. This allows the other servicesto detect problematic compound resource flows. For example, other servicesmay perform asynchronous scanning of uncleared containers and, when found, generate an alert to handle the uncleared containers.

104 124 106 110 124 110 For example, after the transit containeris generated, first servicemay receive a second API call with the transit group ID, requesting to move a resourceinto the transit container. In response, the first servicemoves the resourceto the transit container with a state of the transit container being an inbound pending held state. The inbound pending held and resource held states can be referred to as sub-containers or buckets inside the transit container. At any time, the transit container may contain some resources either one or both of those held states.

124 122 104 124 110 110 110 108 116 124 110 106 110 110 108 108 3 FIG. 4 FIG. 5 FIG. The first servicemay transition the stateof the transit containerto a resource held state, in response to the resource being deemed to be available for additional movement by the first service. For example, if the resourceis a physical asset, this may be deemed available when the resourceis physically in possession or deposited in a physical location. The inbound pending held state may correspond to a request where those resources are in transit into the container, but not yet available (e.g., cargo in transit to a temporary holding location or money scheduled to arrive at an intermediary bank account). If the resourceis a digital resource (e.g., a fund, credit, etc.), then this resource may be deemed available for additional movement when the resource is transferred from an external resource poolor from another digital container (such as another transit container, or a non-transit container) within the server computing system. The first serviceis configured to access the resourceof the transit container which are held in the resource held state, when the first service receives one or more additional API calls, so long as these one or more additional API calls comprise the matching transit group ID. By doing so, other services can link up different inflows or outflows of resource, to serve a compound resource flow. Examples of such compound resource flows are described further, such as with respect to,and. Some or all of resourcemay initially be moved in from an external resource pool, or moved into the external resource poolat the end of the group of movements, or both.

124 106 104 110 104 110 118 124 104 106 First serviceuses the transit group IDas an access control mechanism to the transit containerand resourcestored to the transit container, thereby preventing unauthorized or accidental movement of the resourceby other services. First servicerejects or drops API calls to move resources into or out of a transit container, when the correct transit group IDis not included in the call.

124 104 104 110 104 124 118 104 124 104 218 104 First servicemay release the transit containerfor garbage collection in response to when the transit containersatisfies a condition. For example, if one or more API calls move all of the resourceout of transit container, then first servicemay release transit container for garbage collection. In an embodiment, the condition is satisfied when a specified purpose of the transit container is met. This condition may be generated and stored in memory when the transit container is created. This purpose may be specified as an enumerated value by the calling service that creates the transit container. This mechanism provides flexibility for different use cases of the transit container, and is extensible in that additional use cases may be added on a per-product basis. In some aspects, one of the servicesthat may have access to the transit containertransmit a message to first serviceto indicate that the condition is satisfied. Once discarded, a dedicated garbage collection service may allocate that memory previously occupied by the transit containerto a usable memory pool for future use by the services. In such a manner, the transit containerpersists until it is no longer needed and additional calls need not be wasted to clear them or reallocate the memory for reuse.

104 102 120 104 Each flow of resources in or out of each transit containeris logged to databaseand remains stored in memoryeven after the transit containeris discarded, thereby preserving an accurate record of each resource inflow and outflow.

Various example call flows and resource movements are provided in the present disclosure. New services may be built to create new products that have built in logic to perform the described API calls to suit different clients and different scenarios. Transit container creation can be performed fast and may be archived once the product expects it will not have to handle new resource flows for a given client.

2 FIG. 202 shows an example of a transit container, in accordance with an aspect. Transit containeris an example of a transit container described in other sections, such as with respect to the other figures.

202 202 204 206 208 210 212 206 210 208 202 The transit containermay comprise different states that help to facilitate movements of resources to suit a variety of scenarios that involve related sub-movements. The transit containermay comprise different states such as an inbound pending state, inbound pending held state, resource state, resource held state, and outbound pending state. Some of these states such as the inbound pending held state, resource held state, and resource statemay be associated with its own store for resources within transit container.

202 218 214 214 214 Each time a resource is stored to or moved out of the transit containerfor a specified state (including in-between states of the transit container), servicemay store a corresponding entry in database, which may comprise the source or destination of the movement, or both, depending on availability. The source or destination of the entry may include the state of the container as well as a container identifier (e.g., a name). In an embodiment, when the resource movement is complete and amount of resource within the container is zero, the data corresponding data in the databaseis marked as garbage collected. In such a case, historical movements on the transit container are freed up within database, but, in some embodiments, may be stored in as backups in long term memory storage and/or on an analytics platform.

218 202 218 220 202 218 202 220 202 222 202 202 216 222 Servicemay be a dedicated service that handles requests to move resources into or out of transit container, and may interact with other services of a data server computing system, as described in other section. Servicemay receive one or more API calls such as API callwhich request to move a resource into or out of the transit container. As described, servicecreates transit containerin response to an API callthat may specify that the request to generate a new container is to be a transit container, as opposed to a non-transit container. The transit containeris created with an associated transit group ID, which other services much use to successfully access the transit container. The transit containermay comprise an indicatorwhich indicates that this container is a transit container and carries with it the expectation that the container has each of the shown states and requires the associated transit group IDfor access.

220 202 202 218 202 222 202 An API call such as API callmay move a resource that is stored to the transit containerin one of the states to a different state in the same transit containeror to a different container. Generally, servicemay comprise well defined API endpoints for accessing the transit container, so long as those API calls carry the transit group IDthat corresponds to the transit container.

Table I below describes properties for each state in further detail. These properties for each state are discussed in terms of fungibility vs non-fungibility, resources at-rest vs being in-transit, and how the transit container state maps to a user facing container state.

222 202 Fungibility refers to resources that are in fungible sub-balances which can be moved out of the transit container by any service regardless of which service moved the resource into the container, whereas non-fungible sub-balances ensure strict attribution and inflows/outflows are tracked per transaction and/or per transit group. For example, the calling service must use the transit group IDto move resources into or out of the transit container, thereby acting as a proxy that the calling service is moving the resource on a per-transaction level. A fungible resource is an asset or good that can be readily exchanged for another of the same kind, meaning they are essentially identical and interchangeable, while a non-fungible resource is unique and cannot be replaced with another identical item; each unit has distinct characteristics making it different from others in the same category. Examples of a fungible resource may be a unit of energy (e.g., electricity, wattage, etc.), communication bandwidth (e.g., bytes per second, etc.), currency, a unit of gasoline, a cup of grains, etc. Examples of non-fungible resources are, for example, artwork, sports memorabilia, etc. In some examples, it is beneficial, even if the underlying resource is fungible, to treat it as non-fungible on a per transaction level. This is the case when servicing multiple requests where some of these requests may require multiple sub-data movements, so that resources on the transaction-level are not intermingled and so that each sub-data movement for the larger transaction is allocated a correct portion of the overall resource. In the context of the transit container, the resource is fungible if any service can claim those resources (e.g., without a transit group ID), and non-fungible if only services carrying the right transit group id can claim the resource. Among those services with the right transit group ID, the resources in the transit container are fungible, but through the overall system, those services without the right transit group ID will not be able to access the resource, thereby making the resource fungible based on the transit group ID.

202 218 202 202 222 For example, if the system is used to move X units of gravel from source A to destination B, but we know that Y units of gravel tend to be lost in transit, we can initiate a transaction-level move of X units to the transit container, and then another service can make a subsequent API call (with the right transit group ID) to serviceto move Y units of gravel from source C to the transit container. Another service can make the final API call (also with the right transit group ID) to move X gravel, which has Y+loss added to it, to destination B. Even though gravel here is a fungible resource, each of those calls to move gravel into or out of transit containerrequire the transit group ID, thus making the gravel unique and non-fungible with respect to the transaction-level purpose of moving X units from source A to destination B.

Resources at-rest indicates that backing resource is in-hand and available, and inbound pending or outbound pending indicates the resource is inflight. A service may not assume that the resource is freely available for use (e.g., taking or distribution). For example, the system may initially receive the request to move X units of gravel from source A to destination B, but this X units may still be stored in its original location and is therefore in-transit. When the gravel is loaded in a container, then it may be considered at-rest because it is available and in-hand.

202 222 User-Facing Balance Mapping refers to a mapping between a user facing container representing the total actual resources and the portions of resources that are deemed to be in-transit or pending, as held by the transit container. The user facing container may be accessible by clients of a system that wish to check on status of their resource movement, while transit containermay be an internal data structure or logical representation within the system, comprising the various states and safeguards (e.g., the transit group ID) to support sub-movements of resources as described.

TABLE I Inbound Inbound Pending Pending Held Resource Resource Outbound Core Properties State State State Held State Pending State Fungible or Fungible Non-Fungible Fungible Non-Fungible Non-Fungible Non-Fungible Resources In-Transit In-Transit At-Rest At-Rest In-Transit At-Rest or In-Transit User-Facing Inbound Inbound Resource Outbound Outbound Balance Pending Pending State Pending Pending Mapping State State State State

202 222 218 202 222 222 As described, services may use transit containerfor multiple movements or sub-movements of resources. These movements are tied together by the transit group ID. Each API call to serviceto access the transit containermay comprise this transit group ID, thereby serving as access control based on the inter-relationship between the sub-movements. This mechanism also treats the otherwise fungible resource as non-fungible with respect to that transit group ID, which prevents intermingling of those resources with other of the same resource.

218 202 218 202 204 206 218 222 220 218 220 222 For example, if a resource movement is initiated that calls upon moving X gallons of oil to a final destination, but a portion Y of that amount is to be deposited at an intermediate destination, a first call may be made to serviceto move X gallons into transit container. Servicemay move the X gallons of oil into transit containerunder the inbound pending state, and then into inbound pending held statewhile the X gallons are in transit. At this point, another service may call serviceto move Y gallons to the intermediate destination using the correct transit group IDin the API call. Servicemay reject any API callthat does not specify the correct transit group ID.

202 202 202 202 204 202 202 204 220 The transit containermay comprise enumerated states that may represent the state of the resource as it is deemed to be held by transit container. For example, if a resource is held in transit containerwhile the transit containeris in inbound pending state, this indicates that the resource is on its way to transit container, but not yet in-hand and ready to redistribute. A resource that is stored to transit containerin the inbound pending stateis fully fungible to operations such as bulk advances or delays. For example, another service may call upon the APIto perform a bulk advance of the specified resource or to delay the availability of this resource until a specified time.

206 202 206 202 During the inbound pending held state, services may use the resource storage as a proxy for pending resources that are not to be touched by other services, and while the transit containeris in this state, resources held in resource storage are protected from being bulk-advanced. In other words, while in inbound pending held state, a service is blocked from calling a bulk allocation of all resources stored to transit container.

202 220 202 202 222 202 206 218 220 4 FIG. 5 FIG. In an example, transit containeris used to facilitate a digital transaction (e.g., payment for goods or services). Another service may initiate a payment through API call, and place a resource (e.g., funds in this case) in the transit container. This other service may anticipate that the digital transaction is going to be a multi-movement transaction, and therefore called for the creation of the transit container. The service may receive the transit group IDand share this on a transaction level with other services involved in this transaction. Once the funds are stored to the transit containerin the inbound pending held state, the serviceblocks bulk transfers of this resource, enabling other services to perform sub-movements of this resource so long as they make the API callwith the corresponding transit group ID. In such a manner, different transaction scenarios involving multiple parties and/or multiple resource movements such as those described with respect toandmay be supported.

208 202 208 214 During the resource state, the resource storage holds resources that are backed by actual resources that are available for immediate use. For example, in the case of a gasoline, while the transit containeris in resource state, and databaseholds a value of 12, this may indicate that 12 units (e.g., gallons, barrels, etc.) are available for immediate use and are stored in a corresponding physical storage. In another example, in the case of a computer-network based transaction, this may indicate that funds are placed in a temporary container and are available for immediate use by another service.

210 204 210 During the resource held state, similar to the inbound pending state, this resource held stateallows users to set aside resources for future use. Services may not aggregate on their allocated portion. For example, issuing a resource to be held will set aside that resource so that enough resources are available for a given request.

212 218 202 212 220 202 220 The outbound pending statetracks resources that have been committed for outbound movements but the system is still performing the external leg to move that resource to the destination (e.g., a physical movement of a physical good, or a confirmation of a transfer of funds to a client account). In this state, serviceblocks other services from taking the stored resources but may cancel operations within a specified window—resources are movement-level non-fungible because the only service access to this state is the ability to cancel an individual resource movement. In an example, the system will move the state of the transit containerto outbound pending state, when a call to complete a resource movement is received. Additional API callsmay be performed to move the resource from transit containerto an external container (e.g., to a client-managed database or account). For example, in the case of payments, the system may receive from a client, an event notification that the resource movement has been accepted, and in response, dedicated services will perform the API callsto move the resource to the external container (e.g., a client account).

220 202 218 202 222 202 202 202 222 216 API callmay comprise a plurality of different defined and agreed upon API calls with agreed upon input and return parameters and agreed upon rules and behavior. A first API call (e.g., a transit container creation request) may specify to create a transit container. In response, servicemay generate the transit containerand return a transit group IDfor accessing the transit container. Generating the transit containermay comprise instantiating an object and loading a representative data structure of the transit containerinto memory, including all relevant fields such as, for example, the current state, Transit group ID, an indicatordefining it as being transit capable, etc.

220 202 218 222 218 202 206 202 218 202 206 218 202 210 In an embodiment, API callmay be referred to as an originated resource in (ORI) API call. This API call may specify a source of the resource to be stored to the transit container, and an amount of that resource. When the servicereceives this ORI call with the specified Transit group ID, the servicewill set the transit containerstate to inbound pending held statewhile the resource is in transit to the transit container. The servicewill move this resource to the transit containerin the inbound pending held state. The source may include the source from which the resource is being sent from (e.g., a transit or non-transit container, an external device, etc.). Once the system receives the resource (e.g., a digital confirmation is received by the source that the resource now belongs to the system), the servicesets state of the transit containerto resource held state.

220 218 222 218 210 218 210 218 202 210 212 210 210 202 In an embodiment, an API callmay be referred to as an originated resource out (ORO) API call. When the servicereceives this API call with the Transit group ID, then the servicemay take the resource from resource held state. The servicemoves the taken resource to a resource pool which may be allows those resources to be held by other containers (e.g., other transit or non-transit containers) or otherwise moved by other services or taken externally (e.g., by a client). In an embodiment, when this API call is directed at resource held state, the servicetransitions the transit containerfrom resource held stateto outbound pending stateonce the resource is released to the resource pool. In an embodiment, the service returns the resources to the status from which it was sourced if this API call fails. For example, if an ORO call tries to release an amount of the resource that exceeds that which is in resource held state, the resources are returned to resource held state, thereby protecting the transit containerand stored resource from going negative.

220 224 218 222 210 218 208 218 202 206 210 In an embodiment, an API callmay be referred to as an originated resource transfer (ORT) API call. When servicereceives this ORT API call, it will transfer the resource between a stated source and a stated destination that are specified in the ORT API call. If the ORT API call is received with a Transit group ID, then the stated source and stated destination will be accessed from the resource held state. Otherwise, the servicewill access the resources from the resource state. In an embodiment, the ORT call may specify that delayed availability of the resource is to be applied on the destination side. In this case, the servicemay transition the state of the transit containerto inbound pending held stateand then to resource held state, based on the stated delay.

222 210 206 218 222 By structuring the API calls to require a Transit group IDto access resources in transit states (e.g., resource held stateand inbound pending held state), and by enforcing state-based movement rules for each API call, the servicemay ensure proper flow of the resources between storages, prevent potential negative resource balance, and importantly, maintain grouping of sub-movements of resources within an overarching larger movement of the resource, per the transit group ID.

3 FIG. illustrates an example resource movement scenario with multiple sub-movements, in accordance with an embodiment. Transit containers act as virtual locations that the system leans on to connect interrelated resource movements together.

314 314 316 318 316 318 302 Generally, a server computing systemmay correspond to that which is described in other sections. Server computing systemmay comprise a plurality of services, some of which may handle transit or non-transit containers, others may interact with clients, others may perform strictly application-based logic for different scenarios, etc. In this scenario, a first servicemay receive a first API call (e.g., a transit container creation API call) from one of the other services. In response, first servicemay generate a transit containerin memory that is associated with a transit group ID.

318 308 302 318 302 316 318 316 318 302 The first servicemay receive a second API call (e.g., an ORI call) with the transit group ID to move a resource into the transit container. In response, the first servicemay move the resource to the transit containerwith a state of the transit container being an inbound pending held state. Under this state, the stored resource becomes non-fungible for the purpose of movement of the resource under the specified transit group ID, so that the resource balance under this transit group ID is maintained separate from the overall resource pool that may be otherwise available to other services. The first servicetransitions the state of the transit container to a resource held state, in response to the resource being deemed to be available for additional movement by the first service. At this point, the resource becomes fungible again, but additional servicesmay request the first servicefor access to the resource stored to transit containerin a non-fungible manner, by using API calls with the transit group ID.

318 310 302 304 310 318 302 First servicemay receive a third API call (ORT call) that requests a portion of the resources stored to transit containerbe transferred to a specified destination (second container). This ORT callis called with the requisite transit group ID. In response, first servicemoves the specified portion of the resource from the transit container (e.g., under the inbound pending held state or resource held state of transit container) to the destination transit container.

318 312 302 306 318 302 Additionally, first servicemay receive a fourth API call (ORT call) that requests a remaining portion of the resources stored to transit container, with the requisite transit group ID included in the call, to be moved to a second destination (e.g., third container). In response, first servicemay move the specified remaining portion from the transit container (e.g., under the inbound pending held state or resource held state of transit container) to this third container.

3 FIG. 302 304 306 306 304 In an example, call flow shown inrepresents an inline resource movement which protects the resources stored to transit containerby limiting access based on transit group ID, until each OMT call is received. For example, assuming that X coal is placed on a truck, the first destination of the coal may be sent to a destination associated with second container, and the second and final destination of the coal may be associated with third container. Similarly, in the case of an inline fee during a funds-based transaction, the payment may be split out the inline fee and send it to the third containerwhile moving the remaining funds to second container.

More generally, based on the hidden state-based logic of each transit container, there is no material change in the storage of transaction, resource controls, resource flows, or regulatory tagging, so that the transit container capabilities are added to the system with minimal impact to other operations and services of the system, thereby reducing impact to processing overhead and additional software builds and roll outs.

4 FIG. illustrates an example resource movement scenario with multiple sub-movements, in accordance with an embodiment.

406 406 408 410 408 410 402 Generally, a server computing systemmay correspond to that which is described in other sections. Server computing systemmay comprise a plurality of services, some of which may handle transit or non-transit containers, others may interact with clients, others may perform strictly application-based logic for different scenarios, etc. In this scenario, a first servicemay receive a first API call (e.g., a transit container creation API call) from one of the other services. In response, first servicemay generate a transit containerin memory that is associated with a transit group ID.

410 404 402 410 402 408 410 408 410 402 410 416 408 412 414 402 The first servicemay receive a second API call (e.g., an ORI call) with the transit group ID to move a resource into the transit container. In response, the first servicemay move the resource to the transit containerwith a state of the transit container being an inbound pending held state. Under this state, the stored resource becomes non-fungible for the purpose of movement of the resource under the specified transit group ID, so that the resource balance under this transit group ID is maintained separate from the overall resource pool that may be otherwise available to other services. The first servicetransitions the state of the transit container to a resource held state, in response to the resource being deemed to be available for additional movement by the first service. At this point, the resource becomes fungible again, but additional servicesmay request the first servicefor access to the resource stored to transit containerin a non-fungible manner, by using API calls with the transit group ID. For example, the first servicemay receive a third API call (e.g., ORT call) from one of the serviceswhich transfers a resource amount (e.g., X funds) from the resource stateto resource held stateof transit container. Although not used in this example, the inbound pending state of each transit container may be set when resources are en route into the transit container (e.g., from an external source or other container) and the outbound pending state may be set when resources are en route out of the transit container (e.g., to an external source or other container).

110 410 416 408 412 414 Assuming that resourcecomprises additional resources from previous moves, the first servicemay receive a fourth API call (e.g., OMT call) from one of the plurality of servicesto move Y additional resources from the resource stateto resource held state.

418 408 410 414 402 420 420 420 In response to receiving a fifth API call (e.g., ORT call) from one of the plurality of services, first servicemay transfer the resource (e.g., X+Y amounts of funds) from the resource held stateof the transit containerto container. Containermay be an internal transit or non-transit container. In an embodiment, containermay be an external client account hosted by a client device over a computer network.

408 416 418 402 416 410 412 414 418 414 4 FIG. Dedicated ones of the servicesmake the ORT calland ORT callas part of the same overarching transaction, and therefore, would use the same transit group ID in these calls to access the same transit container. In an example,may illustrate the scenario of a reserve/allocate behavior such as authorization and capture on a credit card. ORT callmay represent an initial issuing authorization of a fund movement for which first servicemoves an initial authorized amount of X funds from resource stateto resource held state. ORT callmoves resources into the resource held stateto add the Y amount of funds, in the case of over capture.

408 418 422 420 For example, X funds are initially authorized to pay for a meal, but X+Y amount is actually needed to successfully pay for the meal (costing X) and a tip (costing Y). Servicesmay interact with external client devices and detect the need to account for this over capture, and make ORT callin the amount of Y to account for what otherwise would be a shortfall when performing the ORT call. Containermay, in this example, represent a client account of the payee (e.g., a restaurant, coffee shop, etc.). Other examples such as, for example, allocation of wireless bandwidth, movement of units of energy, or moving physical commodities (e.g., grains, fuel, gravel, etc.) may also be modeled with this or a different call flow.

5 FIG. illustrates an example resource movement scenario with multiple sub-movements, in accordance with an embodiment.

4 FIG. 520 520 510 524 As described with respect toand other figures, access and movement of resources to or from a transit container is controlled by a service, and may be called upon by other services of a server computing system. Assuming that a user's transit containerhas already been generated and resources are currently stored to user's transit containerusing an ORI, placing these resources in the inbound pending held state. These resources are now non-fungible, and to access them, the requisite transit group ID is needed to be called.

524 522 512 522 518 522 502 504 502 Another service may transmit API call to cause and advance of a portion of the resource stored to inbound pending held stateto move to resource held statewhere it may now be moved to another container. The advance callmay be made by a service to move a portion Y of the in-transit resources not yet in-hand to the resource held state. That same service, or a different service, may make a call (ORT) to move the Y resources from the resource held stateto a different connected container, thereby providing an advance of the resources. The Y resources may be moved to the resource stateof connected container.

510 514 522 510 524 512 522 514 522 516 506 508 506 Further, when the resource from the ORIis deemed to be received (e.g., in-hand), then a service may automatically perform operationand move the balance of the resources to the resource held state. For example, if ORIinitially moved X amount into the inbound pending held state, and advmoved Y amount to the resource held state, then operationmoves X-Y into the resource held state. A service may then make the OMTcall to move those remaining resources (e.g., X-Y amount) to another connected container. This remaining resources may be moved to the resource stateof the connected container. Although not used in this example, the inbound pending state of each transit container may be set when resources are en route into the transit container (e.g., from an external source or other container) and the outbound pending state may be set when resources are en route out of the transit container (e.g., to an external source or other container).

5 FIG. 5 FIG. 510 512 518 516 502 506 522 In an embodiment, the shown call flow incan support movement of physical resource or virtual resources. For example, the ORI may be called upon when a movement of coal is initiated, and that amount of coal may be moved to inbound pending held state. The system may perform the advanceand ORTto signal the advance movement of the coal to a first destination, and then when the coal is in-hand (e.g., on the truck), make the OMTcall and drop the coal two destinations, corresponding to connected containerand connected container. In an embodiment, the shown call flow inmay represent a separate charge and transfer scenario where goods or services may be purchased from a single vendor at the front end, but then those proceeds are to be moved to different vendors or accounts on the back end, and at different times or with different priority levels. The movement of the resources from the inbound pending held state to the resource held statemay be limited by the responsible service, to only advance-based API call with the correct transit group ID, thereby preventing use of in-transit resources other than for an advance, and preventing inadvertent access by other services that are not involved in the overall resource movement.

520 It should be understood that any number of different calls may be performed to control flows of resources between containers and/or between containers and external account. The application-level logic may be performed by one or more dedicated services that may interface with client devices externally and with each other, as described. Generally, the structure of the user's transit containerand the defined API calls support a variety of call flow scenarios that link up sub-resource movements for a related purpose.

6 FIG. illustrates an example mapping of a user facing container and a transit container, in accordance with an embodiment.

602 602 202 602 604 606 608 The user facing containermay be exposed to an external user (e.g., a client, a service, an external device, etc.) and the mapping between the user facing containerand the transit containerhides the complexity of transit-based operations, thereby simplifying and improving experience to a user. For example, a user may transmit a request to a server computing system as described in other sections, and one or more services of the server computing system may return a request to provide the resources currently stored in the user facing containerunder inbound pending, resource, and/or outbound pending.

602 202 202 202 210 206 202 202 210 206 202 202 In an embodiment, when the data processing system receives a request that is associated with a resource movement, the data processing system may generate a user facing containerand associated service. Similarly, the data processing system may generate transit container. Transit containermay support non-transit as well as transit-based capabilities. For example, depending in response to the request being associated with multiple sub-resource movements, the transit containermay be generated (e.g., instantiated) with an indication that resource held stateand inbound pending held stateare supported by the transit container. In response to the request being only a single resource movement, the transit containeris generated without the resource held stateand inbound pending held state. In this manner, the system may need not create or manage additional transit containersto support multiple sub-resource movements, since the transit capabilities are embedded in transit container.

602 610 606 610 202 In an embodiment, the data processing system comprises a dedicated service for user facing container. This dedicated service may be accessible to other services through an API such as, for example, a Remote Procedure Call (RPC) API. In an example, an RPC call may be made from an external service to the user facing serviceto obtain status (e.g., a quantity) of the resource. In an embodiment, user facing servicemay respond to this by returning one or more resource quantities that are mapped to transit container.

604 610 204 206 202 604 For example, if an external service requests the resource quantity associated with inbound pending, the user facing servicemay aggregate all inbound pending stateand inbound pending held stateof the transit containerand return this aggregate as inbound pendingto the external service.

606 610 606 602 208 202 208 In an embodiment, if an external service requests the resource quantity of resource, user facing servicemay directly map the resourceof the user facing containerto the resource stateof the transit container, and return the resource quantity associated with resource state.

608 610 210 212 608 In an embodiment, if an external service requests the resource quantity of outbound pending, the user facing servicemay aggregate resource held stateand outbound pending stateand return this aggregated quantity to the requesting service as outbound pending.

204 206 208 210 212 202 602 202 Because all of these states inbound pending state, inbound pending held state, resource state, resource held state, and outbound pending stateare located within the same transit container, despite the aggregation, user facing containerreads would not suffer from a balance dip or double counting, or zero counting, when moving resources between statuses within the same transit container, as it otherwise would when moving resources between separate non-transit and transit containers.

7 FIG. shows a flow diagram of a method for facilitating resource movements with a transit container, in accordance with an embodiment.

700 700 The methodmay be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), firmware, or a combination. Processing logic may comprise a plurality of processors operating in a distributed computing architecture (e.g., a plurality of services that may be distributed over different servers on a computer network). Each service may be a self-contained buildable and deployable set of machine-executable instructions with dedicated computer resources such as processors, processor bandwidth, network transceiver resources, computer memory, etc. Methodmay be performed by a server computing system or service thereof, as described in other sections.

702 At block, in response to receiving a first API call, processing logic generates a transit container in memory that is associated with a transit group ID. In an example, processing logic may instantiate an object where the object becomes the transit container. Processing logic may generate a unique transit group ID which is associated with this transit container, and return it to the caller of the first API call. In an example, processing logic may comprise a separate API call that returns the transit group ID based on a specified input name or credentials or both. The first API call may be referred to as a transit container creation API call. In an example, the first API call may be an ORI or ORT call to a transit group ID or transit container that does not yet exist. In response, processing logic may create the transit container, and associate it with the specified transit group ID, or provide a new transit group ID to the caller. Processing logic may also perform the ORI or ORT once created.

704 At block, in response to receiving a second API call with the transit group ID to move a resource into the transit container, processing logic moves the resource to the transit container. In an embodiment, this move is performed with a state of the transit container being an inbound pending held state (e.g., a resource is moved from an external pool, into the transit container under the inbound pending held state, and then the resource is transitioned to resource held). In another embodiment, this resource move is performed directly from the external resource pool to the resource held state of the transit container. Each of the states of the transit container may represent its own sub-container that can hold an amount of the resource, for example, the inbound pending held state and the resource held state may each be a separate container for the resource within the transit container. In an embodiment, the second API call may be an ORI call or an ORT call. In an embodiment, the second API call comprises an advance call to advance a portion of the resource from a source to a destination. As described, when resources are stored to the transit container under the inbound pending held state, processing logic may block bulk advances (a request to advance the entire amount of the resource), but partial advances may be approved and performed.

706 At block, processing logic transitions the state of the transit container to a resource held state, in response to the resource being deemed to be received, wherein the first service is configured to access the resource of the transit container in the resource held state in response to one or more additional API calls that comprise the transit group ID. The resource may be deemed to be received by processing logic, based on one or more factors, for example, based on a time threshold, based on a digital confirmation message received over a computer network, based on another service providing the confirmation, or based on one or more sensors detecting that the resource is physically received or present in a designated location, or a combination thereof

708 At block, processing logic releases the transit container for garbage collection in response to when a condition of the transit container is satisfied. In an embodiment, the condition is satisfied when the transit container is depleted of the resource. In another embodiment, the condition comprises a specified purpose of the transit container, which may be generated and stored in memory when the transit container is created. The condition may be deemed to be satisfied when the purpose of the transit container is met (e.g., the resource has been successfully moved to the final destination, or the amount of the resource in the transit container is zero, or both).

The specified purpose may be expressed as a value or an enumerated value, by the calling service that creates the transit container. This provides flexibility for different use cases of the transit container, and is extensible in that additional use cases may be added on a per-product basis. Each calling service initiating the creation of the transit container is expected to know the purpose of each transit container, and may specify it dynamically at the time of creation. The calling service may be part of the product that uses the transit container to move the resource in accordance with a desired workflow.

8 FIG. 8 FIG. is one embodiment of a computer system that may be used to support the systems and operations described, in accordance with an embodiment. For example, the computer system illustrated inmay be used by a forwarding server, a requesting server, a destination endpoint, etc. It will be apparent to those of ordinary skill in the art, however that other alternative systems of various system architectures may also be used.

802 804 808 804 806 804 808 806 808 810 804 808 812 812 804 8 FIG. The computer systemillustrated inincludes a bus or other internal communication meansfor communicating information, and one or more processorscoupled to the busfor processing information. The system further comprises a random access memory (RAM) or other volatile storage device(referred to as memory), coupled to busfor storing information and instructions to be executed by processor. Main memoryalso may be used for storing temporary variables or other intermediate information during execution of instructions by processor. The system also comprises a read only memory (ROM), non-volatile storage, and/or static storage devicecoupled to busfor storing static information and instructions for processor, and a data storage devicesuch as a magnetic disk or optical disk and its corresponding disk drive. Data storage deviceis coupled to busfor storing information and instructions.

814 804 816 818 804 816 808 820 804 816 808 814 The system may further be coupled to a display device, such as a light emitting diode (LED) display or a liquid crystal display (LCD) coupled to busthrough busfor displaying information to a computer user. An alphanumeric input device, including alphanumeric and other keys, may also be coupled to busthrough busfor communicating information and command selections to processor. An additional user input device is cursor control device, such as a touchpad, mouse, a trackball, stylus, or cursor direction keys coupled to busthrough busfor communicating direction information and command selections to processor, and for controlling cursor movement on display device.

802 822 822 822 802 8 FIG. Another device, which may optionally be coupled to computer system, is a communication devicefor accessing other nodes of a distributed system via a network. The communication devicemay include any of a number of commercially available networking peripheral devices such as those used for coupling to an Ethernet, token ring, Internet, or wide area network. The communication devicemay further be a null-modem connection, or any other mechanism that provides connectivity between the computer systemand the outside world. Note that any or all of the components of this system illustrated inand associated hardware may be used in various embodiments as discussed herein.

806 812 808 It will be appreciated by those of ordinary skill in the art that any configuration of the system may be used for various purposes according to the particular implementation. The control logic or software implementing the described embodiments can be stored in main memory, mass storage device, or other storage medium locally or remotely accessible to processor.

806 808 812 808 It will be apparent to those of ordinary skill in the art that the system, method, and process described herein can be implemented as software stored in main memoryor read only memory and executed by processor. This control logic or software may also be resident on an article of manufacture comprising a computer readable medium having computer readable program code embodied therein and being readable by the mass storage deviceand for causing the processorto operate in accordance with the methods and teachings herein.

804 808 806 812 The embodiments discussed herein may also be embodied in a handheld or portable device containing a subset of the computer hardware components described above. For example, the handheld device may be configured to contain only the bus, the processor, and memoryand/or. The handheld device may also be configured to include a set of buttons or input signaling components with which a user may select from a set of available options. The handheld device may also be configured to include an output apparatus such as a liquid crystal display (LCD) or display element matrix for displaying information to a user of the handheld device. Conventional methods may be used to implement such a handheld device. The implementation of embodiments for such a device would be apparent to one of ordinary skill in the art given the disclosure as provided herein.

808 812 804 806 The embodiments discussed herein may also be embodied in a special purpose appliance including a subset of the computer hardware components described above. For example, the appliance may include a processor, a data storage device, a bus, and memory, and only rudimentary communications mechanisms, such as a small touch-screen that permits the user to communicate in a basic manner with the device. In general, the more special-purpose the device is, the fewer of the elements need be present for the device to function.

It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. The scope should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles and practical applications of the various embodiments, to thereby enable others skilled in the art to best utilize the various embodiments with various modifications as may be suited to the particular use contemplated.