Patent ID: 12260437

DETAILED DESCRIPTION

To address the above issues, a computing system10is provided, as shown schematically inFIG.1. The computing system10includes a tax engine server12, a container deployment and management server14, and a transaction log server16, each of which may be hosted in a data center of a tax platform operator, for example. Alternatively, the tax engine server12, container deployment and management server14, and transaction log server16may be configured by the tax platform operator to be hosted at a client-specified data center under control of the client, for performance, security, privacy, and/or export compliance reasons, for example.

Computing system10includes a container builder18executed by a processor of the container deployment and management server14and configured to generate a transaction tax engine container image20that may be deployed at a plurality of on-premises servers22of a client, located at a respective plurality of different geographic locations. The on-premises servers22at the plurality of locations are logically behind a client firewall24that monitors and selectively allows or blocks networking communications to and from the computers situated on the client-side of the firewall, based on a set of security policies.

The tax engine server12has an associated global tax rules database26that includes tax rate and rule data28including tax rates and rules for multiple products and multiple geographic regions for a global list of geographic regions and a global list of products. The tax rates and rules can be indexed by geographic region and product. The tax engine server12further includes a cloud-based transaction tax engine30that is configured to receive a tax calculation request including, for example, a client identifier, product identifier, geographic region identifier, and amount, from a plurality of client applications32. The transaction tax engine30is configured to calculate an applicable tax burden (amount or rate) for the transaction in response to receiving the transaction data, and reply by transmitting the applicable tax burden to the requesting client application32. The applicable burden can be determined from applicable tax rules in the tax rate and rule data28. The communications between transaction tax engine30and the client application32as illustrated at (0) traverse the Internet, and thus are subject to high latency and the attendant issues described above.

It will be appreciated that the global tax rules database26and transaction tax engine30require significant memory requirements due to their large size, and also require deployment on servers that are scalable to address spikes in demand, and also have high availability (e.g., low downtime), and require continuous updating as the tax rules of the various geographic regions around the world change. For these reasons, the tax engine server12is often centrally hosted in a data center of a cloud computing service that offers its platform as a service. However, central hosting in a data center in this manner, as described above, increases transaction latency and bandwidth requirements for the client, and also increases the risk of downtime or failed tax calculation requests when network connectivity from client applications to the data center servers is lost. To address these issues, computing system10utilizes containerization, deployment, and management of a compact and client-localized version of the transaction tax engine30at each client's edge computing devices, as describe below.

An example of the tax rate and rule data28is shown inFIG.2. The tax rate and rule data28includes a rule identification (ID)34, a jurisdiction36, an event38, a condition40, a tax attribute (ATR)42, a start date44, and/or any other suitable information. The rule ID34is an identifier for an individual tax rule and can be numeric or any suitable alphanumeric sequence. The jurisdiction36corresponds to a geographical area where a transaction occurs. The event38includes information relating to the nature of the transaction, such as sale, lease, or rental as examples. The condition40indicates a taxable category associated with the rule ID34. The taxable category can be used to determine an applicable tax rate or rule of the transaction. The tax attribute42indicates how to tax the taxable category, such as taxable, nontaxable, exempt, as examples. When the tax attribute42is taxable, the tax rule has an associated amount or rate (i.e., fee) which can be an actual rate or fee or can be an indicator that a standard rate of the jurisdiction36is to be applied. The start date44can indicate a date to start applying the rule ID34.FIG.2shows a portion of the tax rate and rule data for a single jurisdiction, the city of Seattle, in the tax and rule data28.

Returning toFIG.1, as illustrated at (1), the client may utilize a client administrative device46to access an administrative interface48of the tax engine server12and upload client configuration settings50to the server12. The client configuration settings50may include, for example, a client-specified selection of a subset of products52involved in the transactions, selected from among a global list of products stored at the tax engine server12. Here, “products” means tangible and intangible products and service offerings, e.g., both goods and services that may be subject to transaction taxes, such as sales and use tax, lodging and occupancy tax, etc. The client configuration settings50also may include, for example, a client-specified subset of geographic regions54in which the transactions take place or that govern the transactions due to the location at which they are legally deemed to take place (in the case of an online transaction, for example), which have been selected from among a global list of geographic regions stored at the tax engine server12. The client configuration settings38may further include information on tax exemptions in rule and rate data28that apply to transactions.

FIG.3shows example taxability drivers56of a client-specified selection of a subset of products52involved in the transactions for an example client RetailCo. In this example, RetailCo has two taxpayer entities58, RetailCoNYC, with transactions taking place in New York City, and RetailCoSEA with transactions taking place in the city of Seattle. Each taxpayer entity58has an associated subset of products52each with a product name60. Further, a start date62and an end date64can be set for each of the products52. Each product52is mapped to a taxable category66as shown inFIG.4. The taxable categories66are predefined groups that help to drive the selection of one or more tax rules in the tax rate and rule database28for each geographical area. In the RetailCo example, the product52raingear for the taxpayer58RetailCoSEA is mapped to the taxable category66of rubber pants as indicated at68, and the product52salmon is mapped to the taxable category66of food as indicated at70. The list of the taxability drivers56and the mappings68,70are examples of components of the client configuration settings50.

Returning toFIG.1, the container builder18is executed by the container deployment and management server14or by any suitable server. As shown at (2), the container builder18is configured to extract from the client configuration settings50at the tax engine server12having the associated tax rules database26including tax rate and rule data28for multiple products and multiple geographic regions, and a subset of the multiple products and a subset of the multiple geographic regions applicable to transactions processed by the client. The container builder18is further configured to identify a subset of the tax rate and rule data28A applicable to each of the subset of products in each of the subset of geographic regions54, as shown at (3). This may be accomplished, for example, by querying the tax rules database26for the subset of tax rate and rule data. The container builder18is further configured to create a local edge database including the subset of tax rate and rule data28A and excluding a remainder of the tax rate and rule data. An example subset of the tax rate and rule data28A pertaining to the above example taxpayer RetailCoSEA is shown inFIG.5.

As shown at (4) inFIG.1, the container builder18is further configured to create a transaction tax engine container image20and push the image20to a container registry72. Referring now toFIG.6, the transaction tax engine container image20includes files corresponding to the local edge database74A, an edge version of a tax calculation engine74B, a calculation application programming interface (API)74C for the tax calculation engine, a persistence interface74D to facilitate communication between the local edge database74A and the edge tax calculation engine74B, and a container engine76configured to enable communication between the applications executed (e.g., the transaction tax engine container74) in a container environment and a host operating system78. The local edge database74A can be configured to be an in-memory database upon deployment of the container74at edge computing devices, such as on-premises servers22. It will be appreciated that image20contains files corresponding to these components but is not instantiated as a container and thus has no state.FIG.6shows these components instantiated as a container on the on-premises server22after being received from the container registry72. Returning toFIG.1, the container builder18is further configured to transmit the transaction tax engine container image20to an edge computing device of the client, such as the on-premises servers22. This may be accomplished using the container registry72, which is configured to receive the built transaction tax engine container image20from the container builder18and, as shown at (5), deploy the transaction tax engine container image20on each of the destination devices, e.g., on each of the on-premises servers22. Suitable container registries include DOCKER HUB, AMAZON ELASTIC CONTAINER REGISTRY, AZURE CONTAINER REGISTRY, JFROG, and the like.

Once deployed, the transaction tax engine container images20are instantiated on each of the on-premises servers22, to thereby create container instances for each of the transaction tax engine containers74and associated container engines76executed on each server22. As shown inFIG.6, once instantiated, the calculation API74C of each transaction tax engine container74is configured to receive API calls such as tax calculation requests80through communications mechanisms provided by the host operating system78, from client applications32, such as a shopping cart application, a point-of-sale terminal application, or other transaction software. These API calls may include tax calculation request80to compute a tax burden (amount or rate) for a particular product for a given geographic region. The edge tax calculation engine74B is configured to receive those API calls from the calculation API74C, and process them using the subset of tax rate and rule data28A stored in the local edge database74A, and send a tax calculation response82with the applicable tax amount or rate (e.g., as a computed cost or percentage of the transaction). Further inFIG.6, one example of the client application32is shown executed on the on-premises server22, which may be the same or a different server of the client executing the transaction tax engine containers74. Another example of the client application32is executed on a client computing device83behind the client firewall24, which for example may be a point-of-sale device. In the depicted example, the communications between the client application32and calculation API74C occurs on a low latency connection such as a local area network (LAN), and thus is typically faster than communications that traverse the public Internet, such as if the client computing devices made tax calculation requests to the tax engine server12shown at (0) inFIG.1.

Continuing withFIG.6, the persistence interface74D is configured with a communications stack configured to send telemetry data84through data queue86to a container manager88executed at the container deployment and management server14, also illustrated at (6) inFIG.1. The telemetry data84may include data relating to central processing unit (CPU) usage, memory usage, and transaction performance data such as completion rates and failure rates. The persistence interface74D is also configured to send transaction data90via the data queue86to the container manager88, and accordingly the container manager88of computer system10is configured to receive telemetry data84from the persistence interface74D of the transaction tax engine container74executed on the edge computing device, as illustrated at (7) inFIG.1. The persistence interface74D is also configured to send to the transaction log server16the transaction data90via the data queue86, also illustrated at (8) inFIG.1. The transaction log server16is configured to store the transaction data90in transaction logs91in persistent storage92, illustrated inFIG.1.

An alternate view of computing system10showing communication flows between various functional software modules is shown inFIG.7. Computing system10includes a control center user interface (UI)94where a client can define the client configuration settings for provisioning the transaction tax engine containers. As previously discussed, the client configuration settings may include a subset of products and a subset of geographical regions applicable to the transactions of the client. The control center UI94also provides the client configuration settings to a tax engine extract96configured to extract taxability information from a transaction tax engine hosted on a server, such as tax engine server12, for an edge version of the transaction tax engine.

Computing system10further includes a container builder98configured to combine content and software components used for provisioning a transaction tax engine container image. The content component can include the client configuration settings downloaded from a control center database (DB)100, and a subset of tax rate and rule data applicable to the client-specified products and geographic areas downloaded from a monthly data update (MDU)102. The tax rate and rule data in the monthly data update102can be published monthly to reflect changes in the tax rate and rule data, or at any other suitable interval. The software component can include the extracted taxability information from the tax engine extract96. Further, the container builder98, via a tax engine extract transform and load104, combines and compiles the content and software components to create a transaction tax engine container image which is then uploaded to a S3106. The transaction tax engine container image can be versioned. Further, the container builder98can send binary data relating to the creation of the transaction tax engine container image to artifact repository manager108. The S3106is configured as a staging area for storage of the transaction tax engine container images. The binary data, artifacts, and/or container images stored in S3 bucket106can be copied to a container repository specified by the client. These commercially available repositories include AWS ELASTIC CONTAINER REGISTRY (ECR), DockerHub, JFROG and the like.

The transaction tax engine container image, via an image creation112, are copied from the S3106to a container repository114configured to make available a transaction tax engine container for deployment on a client system, such as on-premises servers22. Suitable container repositories include DOCKER HUB, AWS ELASTIC CONTAINER REPOSITORY (ECR), JFROG, and the like. Deployed transaction tax engine containers74are configured to provide the edge version of the transaction tax calculation engine for client applications32as previously discussed. Further, an update can be accomplished by swapping out one or more of the deployed tax engine containers74with an updated transaction tax engine container. The control center UI94can be used to initiate the update which can be created manually or automatically based on a client-defined schedule or through detection of configuration changes in the transaction tax engine.

The deployed transaction tax engine containers74are configured to send telemetry data and/or transaction data to an authorization module116configured to ensure encryption levels and that the data are authorized, such as via validation of a JSON web token (JWT) for example. The authorized telemetry data is sent to a data stream receiver118, such as a KINESIS STREAMS. The data stream receiver118is configured to help persist telemetry data into a telemetry database120where the telemetry data then can be viewed through the control center UI94. The telemetry data can include metrics such as CPU utilization or transaction performance, as examples. The authorized transaction data is sent to a cloud hosted reporting122via a S3124and a document repository126configured to receive and manage the transaction data for the cloud hosted reporting122. The cloud hosted reporting122is configured to consolidate the transaction data which can be used for reporting, such as preparations for tax returns of the client. Alternatively, the client can use a custom solution instead of the cloud hosted reporting122.

Computing system10further includes tax engine APIs128configured to help support functionality and/or communication between the control center UI94and various services and/or components of the computing system10, such as the container builder98, the S3106, the S3124, and the local edge databases of the containers74. Further, an API gateway130is configured to ensure encryption levels and messages are authorized between the control center UI94and the tax engine APIs128. The messages are authorized via the validation of a JWT token through JWT authorizer132or through any suitable authorization scheme.

FIG.8illustrates a data flow originating with the tax calculation request80from the client application32that are processed by the transaction tax engine container74. The calculation API74C is configured to receive and respond to the tax calculation request80including information relating to the transaction at the client application32(e.g., a date of the transaction, a product being purchased or sold, quantities, amounts, or geographic area). Suitable example formats of the tax calculation request include objects in a SOAP or REST format and the like. Further, the calculation API74C is configured to translate the tax calculation request80into a request object134which is passed on to the edge tax calculation engine74B for processing. The persistence interface74D is configured to provide an interface for the edge tax calculation engine74B to retrieve from the subset of tax rate and rule data28A stored in the local edge database74A applicable tax rate and rule data to process the request object134based on the product(s) and geographic area of the tax calculation request80.

The edge tax calculation engine74B is configured to determine taxes applicable for the tax calculation request80by receiving the request object134from the calculation API74C and using the applicable tax rate and rule data received from the persistence interface74D. More specifically, a combination of a geographic area, a product, and rate and rule data are all mapped together to calculate tax amount and/or tax rate and format a response object136to return to the calculation API74C. In the RetailCoSEA example, the edge tax calculation engine74B will combine the geographic area of Seattle with the product of coffee and then look up the jurisdictions for Seattle, find all the tax rules applicable for the product of coffee, select the applicable tax rule, and calculate the tax burden (amount or rate). The tax calculation response82is sent back to the requesting client application32through the calculation API74C based on the response object136received at the calculation API74C.

The persistence interface74D is further configured to send telemetry data84and/or transaction data90through the data queue86to the container manager88of the container deployment and management server14and/or the transaction log server16through a streaming data pipeline138. The streaming data pipeline138includes an authentication service140such as OAUTH that authenticates the stream, a data stream publishing service142such as AWS KINESIS, which publishes a data stream144, which can be monitored by an event-based monitoring services such as AWS LAMDA.

FIGS.9A-9Bshow a flow diagram of an example method900for generating and deploying an edge version of a tax calculation engine, and processing a tax calculation request at the edge version of the tax calculation engine. Method900may be performed on computing system10for example. Method900comprises, at902, at one or more server devices, generating and deploying a transaction tax engine container, via a container builder, by performing the following steps. Method900comprises, at904, extracting from client configuration settings at a transaction tax server having an associated tax rules database including tax rate and rule data for multiple products and multiple geographic regions, a subset of the multiple products and a subset of the multiple geographic regions applicable to transactions processed by a client. In some examples, the client may have more than one taxpaying entity and each entity can have a different subset of the multiple products and/or a different subset of the multiple geographical regions. Method900comprises, at906, identifying a subset of the tax rate and rule data applicable to each of the subset of products in each of the subset of geographic regions. Method900comprises, at908, creating a local edge database including the subset of the tax rate and rule data and excluding a remainder of the tax rate and rule data. Method900comprises, at910, creating a transaction tax engine container image including the local edge database, along with an edge version of a tax calculation engine. Method900comprises, at912, transmitting the transaction tax engine container image to an edge computing device. Alternatively or additionally, transmitting the transaction tax engine container image is done via a container registry, as indicated at914.

Method900further comprises the following steps at the edge computing device, as indicated at916. Method900comprises, at918, receiving a tax calculation request for a transaction at the tax calculation engine of the container from a client application. The tax calculation request includes a product identifier and a geographic region identifier. In some examples, method900comprises, at920, receiving the tax calculation request over a local area network via a calculation API of the transaction tax engine container. Method900comprises, at922, processing the tax calculation request using the edge version of the tax calculation engine and the local edge database. Method900comprises, at924, sending a tax calculation response for the transaction to the client application. Method900comprises, at926, sending transaction data via a data queue of the transaction tax engine container to the one or more server devices. In some examples, method900comprises, at928, holding the transaction data in the data queue when the edge computing device does not have connectivity. In such examples, the transaction data can be sent to the one or more server devices when the edge computing device reconnects.

Method900performs the following steps at the one or more server devices, as indicated at930. Method900comprises receiving telemetry data for the transaction from the transaction tax engine container executed on the edge computing device at932, and receiving the transaction data for the transaction from the transaction tax engine container executed on the edge computing device at934.

Using the above-described systems and methods, an edge based containerized transaction tax engine can be built, deployed, and executed behind a firewall of a client computer network, to process tax calculation requests from client applications sent over low latency local area network connections, thereby improving response times and decreasing downtime associated with architectures that send tax calculation requests over a wide area network (WAN) such as the internet. This can reduce delays and avoid lost sales through abandoned shopping carts, generally improving the customer experience of the client. Further, the containerized tax calculation engine is built with a sufficiently small footprint, by only including tax rate and rule data related to the geographic regions and products of interest to the client, that it can be executed on computing devices with less memory and processing ability, and still achieve sufficient response times. Such an architecture also has the advantage that fewer tax calculation transactions may fail or time-out, resulting in less tax burden that must be borne by the client due to failure to properly charge tax at the time of the transaction.

In some embodiments, the methods and processes described herein may be tied to a computing system of one or more computing devices. In particular, such methods and processes may be implemented as a computer-application program or service, an application-programming interface (API), a library, and/or other computer-program product.

FIG.10schematically shows a non-limiting embodiment of a computing system1000that can enact one or more of the methods and processes described above. Further, computing system10can be enacted on computing system1000. Computing system1000is shown in simplified form. Computing system1000may embody the servers and computing devices described above. Computing system1000may take the form of one or more personal computers, server computers, tablet computers, home-entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smart phone), and/or other computing devices, and wearable computing devices such as smart wristwatches and head mounted augmented reality devices.

Computing system1000includes a logic processor1002volatile memory1004, and a non-volatile storage device1006. Computing system1000may optionally include a display subsystem1008, input subsystem1010, communication subsystem1012, and/or other components not shown inFIG.10.

Logic processor1002includes one or more physical devices configured to execute instructions. For example, the logic processor may be configured to execute instructions that are part of one or more applications, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions may be implemented to perform a task, implement a data type, transform the state of one or more components, achieve a technical effect, or otherwise arrive at a desired result.

The logic processor may include one or more physical processors (hardware) configured to execute software instructions. Additionally or alternatively, the logic processor may include one or more hardware logic circuits or firmware devices configured to execute hardware-implemented logic or firmware instructions. Processors of the logic processor1002may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel, and/or distributed processing. Individual components of the logic processor optionally may be distributed among two or more separate devices, which may be remotely located and/or configured for coordinated processing. Aspects of the logic processor may be virtualized and executed by remotely accessible, networked computing devices configured in a cloud-computing configuration. In such a case, these virtualized aspects are run on different physical logic processors of various different machines, it will be understood.

Non-volatile storage device1006includes one or more physical devices configured to hold instructions executable by the logic processors to implement the methods and processes described herein. When such methods and processes are implemented, the state of non-volatile storage device1006may be transformed—e.g., to hold different data.

Non-volatile storage device1006may include physical devices that are removable and/or built in. Non-volatile storage device1006may include optical memory (e.g., CD, DVD, HD-DVD, Blu-Ray Disc, etc.), semiconductor memory (e.g., ROM, EPROM, EEPROM, FLASH memory, etc.), and/or magnetic memory (e.g., hard-disk drive, floppy-disk drive, tape drive, MRAM, etc.), or other mass storage device technology. Non-volatile storage device1006may include nonvolatile, dynamic, static, read/write, read-only, sequential-access, location-addressable, file-addressable, and/or content-addressable devices. It will be appreciated that non-volatile storage device1006is configured to hold instructions even when power is cut to the non-volatile storage device1006.

Volatile memory1004may include physical devices that include random access memory. Volatile memory1004is typically utilized by logic processor1002to temporarily store information during processing of software instructions. It will be appreciated that volatile memory1004typically does not continue to store instructions when power is cut to the volatile memory1004.

Aspects of logic processor1002, volatile memory1004, and non-volatile storage device1006may be integrated together into one or more hardware-logic components. Such hardware-logic components may include field-programmable gate arrays (FPGAs), program- and application-specific integrated circuits (PASIC/ASICs), program- and application-specific standard products (PSSP/ASSPs), system-on-a-chip (SOC), and complex programmable logic devices (CPLDs), for example.

The terms “module,” “program,” and “engine” may be used to describe an aspect of computing system1000typically implemented in software by a processor to perform a particular function using portions of volatile memory, which function involves transformative processing that specially configures the processor to perform the function. Thus, a module, program, or engine may be instantiated via logic processor1002executing instructions held by non-volatile storage device1006, using portions of volatile memory1004. It will be understood that different modules, programs, and/or engines may be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Likewise, the same module, program, and/or engine may be instantiated by different applications, services, code blocks, objects, routines, APIs, functions, etc. The terms “module,” “program,” and “engine” may encompass individual or groups of executable files, data files, libraries, drivers, scripts, database records, etc.

When included, display subsystem1008may be used to present a visual representation of data held by non-volatile storage device1006. The visual representation may take the form of a graphical user interface (GUI). As the herein described methods and processes change the data held by the non-volatile storage device, and thus transform the state of the non-volatile storage device, the state of display subsystem1008may likewise be transformed to visually represent changes in the underlying data. Display subsystem1008may include one or more display devices utilizing virtually any type of technology. Such display devices may be combined with logic processor1002, volatile memory1004, and/or non-volatile storage device1006in a shared enclosure, or such display devices may be peripheral display devices.

When included, input subsystem1010may comprise or interface with one or more user-input devices such as a keyboard, mouse, touch screen, or game controller. In some embodiments, the input subsystem may comprise or interface with selected natural user input (NUI) componentry. Such componentry may be integrated or peripheral, and the transduction and/or processing of input actions may be handled on- or off-board. Example NUI componentry may include a microphone for speech and/or voice recognition; an infrared, color, stereoscopic, and/or depth camera for machine vision and/or gesture recognition; a head tracker, eye tracker, accelerometer, and/or gyroscope for motion detection and/or intent recognition; as well as electric-field sensing componentry for assessing brain activity; and/or any other suitable sensor.

When included, communication subsystem1012may be configured to communicatively couple various computing devices described herein with each other, and with other devices. Communication subsystem1012may include wired and/or wireless communication devices compatible with one or more different communication protocols. As non-limiting examples, the communication subsystem may be configured for communication via a wireless telephone network, or a wired or wireless local- or wide-area network, such as a HDMI over Wi-Fi connection. In some embodiments, the communication subsystem may allow computing system1000to send and/or receive messages to and/or from other devices via a network such as the Internet.

It will be understood that the configurations and/or approaches described herein are exemplary in nature, and that these specific embodiments or examples are not to be considered in a limiting sense, because numerous variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. As such, various acts illustrated and/or described may be performed in the sequence illustrated and/or described, in other sequences, in parallel, or omitted. Likewise, the order of the above-described processes may be changed.

The subject matter of the present disclosure includes all novel and non-obvious combinations and sub-combinations of the various processes, systems and configurations, and other features, functions, acts, and/or properties disclosed herein, as well as any and all equivalents thereof.