Patent ID: 12216660

DETAILED DESCRIPTION

The description that follows includes systems, methods, techniques, instruction sequences, and computing machine program products that embody illustrative embodiments of the disclosure. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known structures and methods associated with underlying technology have not been shown or described in detail to avoid unnecessarily obscuring descriptions of the preferred embodiments.

FIG.1is a diagram showing sample aspects of embodiments of the present disclosure involving receiving input indicating a client has selected an automatic activities option to automatically start activities upon crossing a threshold, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

A thick line115separates this diagram, although not completely or rigorously, into a top portion and a bottom portion. Above the line115the emphasis is mostly on entities, components, their relationships, and their interactions, while below the line115emphasis is mostly on processing of data that takes place often within one or more of the components above the line115.

Above the line115, the sample computer system195, network188, client computer system190and secondary entity196according to embodiments is shown. The computer system195has one or more processors194and a memory130. The memory130stores programs131and data138. The one or more processors194and the memory130of the computer system195thus implement a service engine183. Additional implementation details for the computer system195are given later in this document.

The computer system195can be located in “the cloud.” In fact, the computer system195may optionally be implemented as part of an online software platform (OSP)198. The OSP198can be configured to perform one or more predefined services, for example, via operations of the service engine183. Such services can be, but are not limited to: producing respective resources by applying digital rules to respective datasets received by clients, such as client193; automatically start or stop activities, including producing respective resources, upon a threshold being crossed, such as may be determined based on the application of digital rules to respective datasets received by clients; causing notifications to be transmitted to clients about aspects of produced resources; and so on, including what is described in this document. Such services can be provided as a Software as a Service (SaaS).

A user192may be standalone. The user192may use a computer system190that has a screen191, on which User Interfaces (UIs) may be shown. Additional sample implementation details for the computer system190are given later in this document. In embodiments, the user192and the computer system190are considered part of a primary entity, such as client193, which can be referred to also merely as entity. In such instances, the user192can be an agent of the entity193, and even within a physical site of the entity193, although that is not necessary. In embodiments, the computer system190or other device of the user192or the entity193are client devices for the computer system195.

The computer system190may access the computer system195via a communication network188, such as the internet. In particular, the entities and associated systems ofFIG.1may communicate via physical and logical channels of the communication network188. For example, information may be communicated as data using the Internet Protocol (IP) suite over a packet-switched network such as the Internet or other packet-switched network, which may be included as part of the communication network188. The communication network188may include many different types of computer networks and communication media including those utilized by various different physical and logical channels of communication, now known or later developed. Non-limiting media and communication channel examples include one or more, or any operable combination of: fiber optic systems, satellite systems, cable systems, microwave systems, asynchronous transfer mode (“ATM”) systems, frame relay systems, digital subscriber line (“DSL”) systems, radio frequency (“RF”) systems, telephone systems, cellular systems, other wireless systems, and the Internet. In various embodiments the communication network188can be or include any type of network, such as a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), or the internet.

Downloading or uploading may be permitted from one of these two computer systems to the other, and so on. Such accessing can be performed, for instance, with manually uploading files, like spreadsheet files, etc. Such accessing can also be performed automatically as shown in the example ofFIG.1. The computer system190and the computer system195may exchange requests and responses with each other. Such can be implemented with a number of architectures.

In one such architecture, a device remote to the service engine183, such as computer system190, may have a certain application (not shown) and a connector (not shown) that is a plugin that sits on top of that certain application. The connector may be able to fetch from the remote device the details required for the service desired from the OSP198, form an object or payload134, and then send or push a request184that carries the payload134to the service engine183via a service call. The service engine183may receive the request184with the payload134. The request184may also include particular option selections regarding the one or more predefined services that the OSP198can be configured to perform, such as automatic activities option selection(s)140that may trigger the service engine183to automatically start one or more activities upon one or more thresholds being crossed.

The service engine183may then apply digital rules170to the payload134to determine whether or not to automatically start or stop activities, including producing respective resources, upon a threshold being crossed, to determine a requested resource179, form a payload137that is an aspect of the resource179, and then push, send, or otherwise cause to be transmitted a response187that carries the payload137to the connector. The connector reads the response187and forwards the payload137to the certain application. In some embodiments, the OSP198may generate and deliver a software development kit (SDK) (not shown) including libraries, documentation, code samples, processes, and guides that the client193can use and integrate with the connector and other applications of the computer system190to implement functionality described herein. The SDK may be a collection of software development tools in one package installable by the client computer system190. The SDK may facilitate the creation of applications by having a compiler, debugger and a software framework. The SDK may include libraries, documentation, code samples, processes, and guides that the client193can use and integrate with the connector and other applications of the computer system190to implement the functionality described herein. In various embodiments, the connector may have been built by the client193, the OSP198or another entity. The client193may use the SDK for controlling the developing and adjusting, from the client-side, operations of the connector.

In an alternative such architecture, a device remote to the service engine183, such as computer system190, may have a particular application (not shown). In addition, the computer system195may implement a REST (Representational State Transfer) API (Application Programming Interface) (not shown). REST or RESTful API design is designed to take advantage of existing protocols. While REST can be used over nearly any protocol, it usually takes advantage of HTTP (Hyper Text Transfer Protocol) when used for Web APIs. This alternative architecture enables the client193to directly consume a REST API from their particular application, without using a connector. The particular application of the remote device may be able to fetch internally from the remote device the details required for the service desired from the OSP198, and thus send or push the request184to the REST API. In turn, the REST API talks in background to the service engine183. Again, the service engine183determines the requested resource179, and sends an aspect of it back to the REST API. In turn, the REST API sends the response187that has the payload137to the particular application.

Moreover, in some embodiments, data from the computer system190and/or from the computer system195may be stored in an Online Processing Facility (OPF)189that can run software applications, perform operations, and so on. In such embodiments, requests and responses may be exchanged with the OPF189, downloading or uploading may involve the OPF189, and so on. In such embodiments, the computer system190and any devices of the OPF189can be considered to be remote devices, at least from the perspective of the computer system195.

In some instances, the user192or the client193may have instances of relationships with secondary entities. Only one such secondary entity196is shown. However, additional secondary entities may be present in various other embodiments. For example, the client193may have a relationship instance197with the secondary entity196via an intermediary entity (not shown).

In some instances, the user192and the client193may have data about one or more secondary entities, for example via relationship instances of the user192or primary entity with the secondary entity196. The client193, an intermediary entity and/or the secondary entity196may be referred to as simply entities. One of these entities may have one or more attributes. Such an attribute of such an entity may be any one of its name, type of entity, a physical or geographical location such as an address, a contact information element, an affiliation, a characterization of another entity, a characterization by another entity, an association or relationship with another entity (general or specific instances), an asset of the entity, a declaration by or on behalf of the entity, and so on.

In embodiments, the computer system190generates one or more datasets. A sample generated dataset135is shown below the line115. The dataset135has values that can be numerical, alphanumeric, Boolean, and so on, as needed for what the values characterize. For example, an identity value ID may indicate an identity of the dataset135, so as to differentiate it from other such datasets. At least one of the values of the dataset135may characterize an attribute of a certain one of the entities193and196. (It should be noted that the arrows199describe a correspondence, but not the journey of data in becoming the dataset135.) For instance, a value D1 may be the name of the certain entity, a value D2 may be for relevant data of the entity, and so on. Plus, an optional value B1 may be a numerical base value for an aspect of the dataset, and so on. The aspect of the dataset may be the aspect of the value that characterizes the attribute, an aspect of the reason that the dataset was created in the first place, an indication of an identity or other characteristic of the client193and/or the secondary entity196, etc. The dataset135may further have additional such values, as indicated by the horizontal dot-dot-dot to the right of the dataset135. In some embodiments, the dataset135has values that characterize attributes of each of the client193and the secondary entity196, but that is not required.

In embodiments, stored digital rules170may be accessed by the computer system195. These rules170are digital in that they are implemented for use by software. For example, these rules170may be implemented within programs131and data138. The data portion of these rules170may alternately be implemented in memories in other places, which can be accessed via the network188. These rules170may be accessed responsive to receiving a dataset, such as the dataset135.

The digital rules170may include main rules, which can thus be accessed by the computer system195. In this example, three sample digital main rules are shown explicitly, namely M_RULE5175, M_RULE6176, and M_RULE7177. In this example, the digital rules170also include digital precedence rules P_RULE2172and P_RULE3173, which can thus be further accessed by the computer system195. The digital rules170may include additional rules and types of rules, as suggested by the vertical dot-dot-dots.

In embodiments, a certain one of the digital main rules may be identified from among the accessed stored rules by the computer system195. In particular, values of the dataset135can be tested, according to arrows171, against logical conditions of the digital main rules, as described later in this document. In this example, the certain main rule M_RULE5175is thus identified, which is indicated also by the beginning of an arrow178that is described in more detail later in this document. Identifying may be performed in a number of ways depending on how the digital main rules are implemented. An example is now described.

Referring now also toFIG.2, some of the digital main rules of digital rules170are repeated fromFIG.1in more detail. In addition, according to an arrow270, these digital main rules are shown juxtaposed with a flowchart portion200. In embodiments, some of the digital main rules can be expressed in the form of a logical “if-then” statement, such as: “if P then Q”. In such statements, the “if” part, represented by the “P”, is called the condition, and the “then” part, represented by the “Q”, is called the consequent. Therefore, at least some of the digital main rules include respective conditions and respective consequents associated with the respective conditions, respectively. And, for a certain digital main rule, if its certain condition P is met, then its certain consequent Q is what happens or becomes applied. Of course, one or more of the digital rules170may have more than one conditions P that both must be met, and so on. And some of these digital rules170may be searched for, and grouped, according first to one of the conditions, and then the other. In this example, the digital main rules M_RULE5175, M_RULE6176, and M_RULE7177ofFIG.1, include respective conditions CN5, CN6, CN7, and respective consequents CT5, CT6, CT7 associated with the respective conditions CN5, CN6, CN7, respectively.

In embodiments, therefore, identifying is performed by recognizing, by the computer system195, that a certain condition of a certain one of the accessed digital main rules is met by one or more of the values of the dataset. An example of the operations of recognizing that a condition is met and thus identifying an applicable rule is shown by flowchart portion200ofFIG.2. According to successive decision diamonds285,286,287, it is determined whether or not conditions CN5, CN6, CN7 are met by at least one of the values of the dataset, respectively. If the answer is NO, then execution may proceed to the next diamond. If the answer is YES then, according to operations295,296,297, it is further determined that the respective consequents CT5, CT6, CT7 are to be applied, and then execution may proceed to the next diamond in the flowchart portion. A consequent that is to be applied could be, for example, flagged as TRUE.

From what was mentioned in connection withFIG.1, the certain M_RULE5175was thus identified. With reference toFIG.2, the identification may have happened at operation285of the flowchart portion200, at which time it was recognized that condition CN5 was met by a value of the dataset135. This made: the condition CN5 be the certain condition, the digital main rule M_RULE5175be the certain digital main rule, and the consequent CT5 be the certain consequent of the certain digital main rule M_RULE5175. And the certain consequent CT5 is associated with the certain condition CN5, since both are included by the certain digital main rule M_RULE5175. Therefore, according to operation295, consequent CT5 is what happens or becomes applied, as described below.

A number of examples are possible for how to recognize that a certain condition of a certain digital rule is met by at least one of the values of the dataset. For instance, the certain condition could define a boundary of a region that is within a space. The region could be geometric, and even be within a larger space and may include political boundaries. For example, the region could be geographic, within the space of a city, a county, a state, a country, a continent or the earth. The boundary of the region could be defined in terms of numbers according to a coordinate system within the space. In the example of geography, the boundary could be defined in terms of groups of longitude and latitude coordinates. In such embodiments, the certain condition could be met responsive to the characterized attribute of the dataset being in the space and within the boundary of the region instead of outside the boundary. For instance, the attribute could be a location of the entity, and the one or more values of the dataset135that characterize the location could be one or more numbers or an address, or longitude and latitude. The condition can be met depending on how the one or more values compare with the boundary. For example, the comparison may reveal that the location is in the region instead of outside the region. The comparison can be made by rendering the characterized attribute in units comparable to those of the boundary. For example, the characterized attribute could be an address that is rendered into longitude and latitude coordinates, and so on.

In an example embodiment, the certain condition could define a threshold that needs to be crossed for an activity to be started or stopped. In such embodiments, the certain condition could be met responsive to a value based on one or more of the characterized attributes of one or more datasets, either individually or in aggregate, crossing the threshold.

The above embodiments are only examples, and not limiting. For instance, the example ofFIG.2suggests that there is a one-to-one correspondence of the conditions with the associated consequents, but that is not necessary. In fact, a single consequent may be associated with two or more conditions, and two or more consequents may be associated with a single condition. Of course, all such can be shown as additional rules, with groups of them having the same condition or consequent.

For another instance, once it is determined that a consequent is to be applied, execution may even exit the flowchart portion200. Or, as shown, it may be determined that more than one of the digital main rules is to be applied. In particular, operation285may give the answer YES such that consequent CT5 is to be applied, and operation286may also give the answer YES such that consequent CT6 is to be applied.

Where more than one of the digital main rules are found that could be applied, there are additional possibilities. For instance, the computer system195ofFIG.1may further access at least one stored digital precedence rule, such as P_RULE2172or P_RULE3173. Accordingly, the certain digital main rule may be thus identified also from the digital precedence rule. In particular, the digital precedence rule may decide which one or more of the digital main rules is to be applied. To continue the previous example, if a value of the dataset135that characterizes a location, and the location is within multiple overlapping regions according to multiple rules, the digital precedence rule may decide that all of them are to be applied, or less than all of them are to be applied. Equivalent embodiments are also possible, where digital precedence rules are applied first to limit the iterative search of the flowchart portion200, so as to test the applicability of fewer than all the rules according to arrows171.

In embodiments, a resource may be produced for the dataset135, and/or other activities may be automatically started or stopped, by the computer system195applying the certain consequent of the certain digital main rule. The resource can be a computational result, a document, an item of value, a representation of an item of value, etc., made, created or prepared for the user192, the client193and/or the secondary entity196, etc., on the basis of the attribute. As such, in some embodiments, the resource is produced by a determination and/or a computation. In the example ofFIG.1, a resource179is produced for the dataset135, by the computer system195applying the certain M_RULE5175, and in particular its certain consequent CT5, as indicated by the arrow178. In fact, sometimes applying the consequent is more simply stated as “applying the rule”.

The resource may be produced in a number of ways. For example, the certain consequent can be applied to one of the values of the dataset135. For instance, one of the values of the dataset135can be a numerical base value, e.g. B1, that encodes an aspect of the dataset135, as mentioned above. In such cases, applying the certain consequent may include performing a mathematical operation on the base value B1. For example, applying the certain consequent may include multiplying the base value B1 with a number indicated by the certain consequent. Such a number can be, for example, a percentage, e.g., 1.5%, 3%, 5%, and so on. Such a number can be indicated directly by the certain rule, or be stored in a place indicated by the certain rule, and so on.

As mentioned above, in some embodiments two or more digital main rules may be applied. For instance, referring again toFIG.1, the computer system195may recognize that an additional condition of an additional one of the accessed digital main rules170is met by at least one of the values of the dataset135, either alone or in combination with other values of other datasets. In this example there would be no digital precedence rules, or the available digital precedence rules would not preclude both the certain digital main rule and the additional digital main rule from being applied concurrently. Such an additional digital main rule would have an additional consequent.

In such embodiments, the resource may be produced by the computer system applying the certain consequent and the additional consequent. For instance, where the base value B1 is used, applying the certain consequent may include multiplying the base value B1 with a first number indicated by the certain consequent, so as to compute a first product. In addition, applying the additional consequent may include multiplying the base value B1 with a second number indicated by the additional consequent, so as to compute a second product. And, the resource may be produced by summing the first product and the second product.

In embodiments, a notification can be caused to be transmitted, e.g., via the network188, by the computer system. The notification can be about an aspect of the resource, that a condition is met or no longer met, a warning that a condition is or about to be met or no longer be met, that an activity has been or is about to be automatically started or stopped based on a condition being met or no longer being met, and/or include an option to enable or select a setting regarding a service provided by the OSP198. In the example ofFIG.1, a notification136can be caused to be transmitted by the computer system195, for example as an answer or other response to the received dataset135. The notification136can be about an aspect of the produced resource179. In particular, the notification136may inform about the aspect of the resource179, namely that it has been determined, where it can be found, what it is, or at least a portion or a statistic of its content, a rounded version of it, and so on. The planning should be that the recipient of the notification136understands what it is being provided.

The notification136can be transmitted to one of an output device and another device. The output device may be the screen of a local user or a remote user. The notification136may thus cause a desired image, message, or other such notification to appear on the screen, such as within a Graphical User Interface (GUI) and so on. The other device can be the remote device, from which the dataset135was received, as in the example ofFIG.1. In particular, the computer system195may cause the notification136to be communicated by being encoded as a payload137, which is carried by a response187. The response187may be transmitted via the network188responsive to the received request184. The response187may be transmitted to the computer system190, or to OPF189, and so on. As such, the other device can be the computer system190, or the OPF189, or the screen191of the user192, and so on. In this example, the single payload137encodes the entire notification136, but that is not required. Similarly with what is written above about encoding datasets in payloads, the notification136instead may be provided via two or more payloads, or in other cases the notification136and at least one other notification may be included in the same single payload. Along with the aspect of the resource179, it can be advantageous to embed in the payload137the identity value (ID) and/or one or more values of the dataset135. This will help the recipient correlate the response187to the request184, and therefore match the received aspect of the resource179as the answer or other response to the appropriate dataset.

In an example embodiment, there may be a plurality of relationship instances between the client193and one or more secondary entities, such as secondary entity196. In some embodiments, such relationship instances are between the client193and one or more secondary entities, such as secondary entity196, via one or more intermediary entities (not shown). Each relationship instance may be associated with one or more respective domains of a plurality of domains. In various embodiments, a domain may be a region defined by a boundary as discussed above or may be an entity representing or otherwise associated with the region. For example, the region could be geographic, within the space of a city, a county, a state, a country, a continent or the earth.

For example, in one embodiment, client193may have a relationship instance197with secondary entity196and that particular relationship instance197may be associated with one or more domains. The association of the relationship instance197with the one or more domains may be based on a variety of characteristics including, but not limited to: a relationship of one or more of the primary entity and secondary entity with the particular domain; a location of one or more of the primary entity and secondary entity within or associated with the particular domain; a region or location associated with one or more of the primary entity and secondary entity being within or associated with the particular domain; a previous relationship of one or more of the primary entity and secondary entity with the particular domain; a location of items associated with one or more of the primary entity and secondary entity within the particular domain; a number of relationships of one or more of the primary entity and secondary entity with the particular domain; a transfer of items associated with one or more of the primary entity and secondary entity to or from an entity within or associated with the particular domain; a transfer of data associated with one or more of the primary entity and secondary entity to or from an entity within or associated the particular domain, etc. The existence or identification of the relationship instance197and/or one or more characteristics of the relationship instance197may be defined or represented by values of dataset135.

In some embodiments, for each relationship instance of the plurality of relationship instances represented by dataset135, the OSP198electronically identifies a rate to calculate an amount of resource due to one or more respective domains associated with the relationship instance based on particular attributes of the dataset135and the one or more respective domains. For example, the client193may send request184to the computer system195of OSP198for services that include producing resources based on the dataset135. The request184may include the existence or identification of the relationship instance197and/or one or more characteristics of the relationship instance197as part of payload134. The service engine183may then apply digital rules170to the relationship instance197and/or one or more characteristics of the relationship instance197to identify or otherwise determine the rate to calculate an amount of resource due to one or more respective domains associated with the relationship instance.

For example, digital precedence rule P_RULE2172may decide that rule M_RULE5175is to be applied when a particular condition is met. Digital precedence rule P_RULE2172may include a condition that indicates if a particular relationship instance is associated with a particular domain and/or a particular threshold has been crossed due to or otherwise regarding one or more attributes of the relationship instance, either alone or in combination with attributes of other relationship instances, then rule M_RULE5175is to be applied. The service engine183may determine that the condition is met due to one or more values of dataset135indicating the particular relationship instance and that the particular relationship instance is associated with the particular domain and/or a particular threshold has been crossed due to or otherwise regarding one or more attributes of the relationship instance, either alone or in combination with attributes of other relationship instances. Thus, as a consequent of precedence rule P_RULE2172, the service engine183applies rule M_RULE5175. Rule M_RULE5175may include a condition CN5 that indicates if a relationship instance is associated with that particular domain, then, as consequent CT5, a particular rate is to be used to calculate an amount of resource due to that particular domain.

Referring again toFIG.2, at decision diamond285it is determined that the condition CN5 is met (i.e., that a particular attribute of the dataset is associated with a particular domain) and thus, the particular rate is used to calculate an amount of resource due to that particular domain. Thus, by applying digital rules170, the service engine183identifies the rate to calculate an amount of resource due to one or more respective domains associated with the relationship instance based on one or more attributes of the dataset135, and also calculates an amount of resources due to at least one respective domain associated with the relationship instance based on the identified rate. In some embodiments, this calculated amount of resources due may be included by the service engine183as part of the resulting produced resource179and/or notification136. The service engine183may then form a payload137that is an aspect of the resource179, and then push, send, or otherwise cause to be transmitted a response187that carries the payload137to a device remote to the service engine183, such as computer system190, a device of secondary entity196or another secondary entity. Digital rules170may include multiple different digital rules for each type of relationship instance and different domains. In various embodiments, the notification136may comprise the response187, or the response187may be included in the notification136.

The OSP198may also provide a selectable option to the client193to have the OSP198to automatically start or stop activities, such as production of resources for datasets associated with one or more particular domains, upon one or more respective thresholds associated with the particular domains being crossed regarding the datasets of the client193received by the OSP198. The OSP198may receive a first input, such as automatic activities option selection(s)140as part of request184, indicating whether or not the client has selected the option. In some embodiments, automatic activities option selection(s)140may be received with, in conjunction with, or as part of the payload134. In some embodiments, the request184may include the dataset135. However, in the present embodiment, the automatic activities option selection(s)140are received before the dataset135. In various embodiments, the automatic activities option selection(s)140may be received by the OSP198during or after the initial onboarding or subscription of the client193to the services of the OSP198.

FIG.3is a flowchart for illustrating a sample method300for automatically producing a resource based on a threshold being crossed, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

Although, in the present example, the operations and methods described with reference to the flowcharts illustrated inFIGS.3,4,6-8and12are described as being performed by the OSP198, in various embodiments, one or more of the operations and methods described with reference to the flowcharts illustrated inFIGS.3,4,6-8and12or otherwise described herein may be performed by the client computer system190of client193.

At302the OSP198receives a dataset on behalf of a primary entity, in which the dataset includes data regarding a relationship instance associated with the primary entity.

At304the OSP198determines a domain associated with the relationship instance.

At306, the OSP198parses from the dataset a base value associated with the dataset.

At308, the OSP accesses an electronic true/false flag associated with the primary entity and with the domain.

At310, the OSP198checks a flag status of the true/false flag. If the flag status is false, the method proceeds to318. If the flag status is true, the method proceeds to312. Also, in response to the flag status being set from false to true, the OSP198may transmit a notification to a computer system of the domain regarding a registration for the client with the domain for remitting resources for relationship instances associated with the domain.

At312, the OSP198looks up a rate applicable to the dataset based on the domain.

At314, the OSP198produces, based on the rate and the parsed base value, a resource having a nonzero value and that is associated with the relationship instance. In some embodiments, setting the flag status occurs after the producing the resource. In some embodiments, setting the flag status occurs before the producing the resource and the flag status is rechecked before the producing the resource.

At316, the OSP198transmits a notification regarding the resource associated with relationship instance.

At318, the OSP198looks up a first threshold associated with the domain and a second threshold associated with the domain. On various embodiments, the first threshold and the second threshold are defined by one or more digital rules about relationship instances associated with the domain.

At320, the OSP198accesses a first counter associated with the primary entity and the domain.

At322, the OSP198increments the first counter responsive to receiving the dataset. In some embodiments, the OSP198determine whether one or more digital rules about relationship instances associated with the domain indicate to not count a relationship instance for purposes of determining whether the first counter meets or exceeds the first threshold if an exemption is associated with the relationship instance. In such embodiments, the OSP198determines whether an exemption is associated with the relationship instance and the incrementing the first counter is based on a determination that there is not an exemption associated with the relationship instance.

At324, the OSP198sets the flag status to true if the first counter meets or exceeds the first threshold after the incrementing.

At326, the OSP198accesses a second counter representing a present base value associated with the primary entity and the domain. The OSP198may parse from the dataset an identity of the primary entity and the domain associated with the relationship instance for the accessing of the first counter and the second counter.

At328, the OSP198updates the second counter responsive to and based on the parsed base value. In some embodiments, the OSP198may re-set one or more of the first counter and the second counter based on a period of time that has passed since a selectable calendar date. The OSP198may look up the selectable calendar date from a stored memory entry.

At330, the OSP198sets the flag status to true if the second counter meets or exceeds the second threshold after updating the second counter. Also, in some embodiments, the OSP198may determine, according to a warning criterion, that the first counter is approaching the first threshold or that the second counter is approaching the second threshold. In such embodiments, the OSP198may then transmit a warning notification to a client system associated with the primary entity responsive to thus determining according to the warning criterion.

At332, the OSP198checks a flag status of the true/false flag. If the flag status is false, the method proceeds to334. If the flag status is true, the method proceeds to312.

At334, the OSP198produces a resource having a zero value and that is associated with the relationship instance. In some embodiments, setting the flag status occurs after the producing the resource. In other embodiments, setting the flag status occurs before the producing the resource and the flag status is rechecked before the producing the resource. Also, in some embodiments, the OSP198may provide and receive an option setting from the primary entity before determining the domain of the relationship instance. In such embodiments, the flag status is thus set only if the option setting has been thus received, else the flag status is not thus set if the option setting has not been thus received.

The OSP198may receive a plurality of additional datasets on behalf of the primary entity. Each dataset of the plurality of additional datasets includes data regarding a respective additional relationship instance associated with the primary entity and with a respective additional domain associated with the respective additional relationship instance. For each of the additional datasets, the OSP198processes the additional datasets and produces additional respective resources based thereon in the manner described herein regarding method300.

FIG.4is a flowchart for illustrating a sample method400for looking up a first threshold associated with the domain and a second threshold associated with the domain that is useful in the method300ofFIG.3, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

At402, the OSP198looks up the first threshold from digital rules that are specific to the domain associated with the relationship instance.

At404, the OSP198looks up the second threshold from the digital rules that are specific to the domain associated with the relationship instance.

FIG.5is a data structure500including example values of counters, threshold levels and resulting flag states for a plurality of domains in a system that implements the method300ofFIG.3for automatically producing a resource based on a threshold being crossed according to embodiments of the present disclosure, which is an improvement in automated computerized systems. For domain TJA, domain TJB and domain TJC, shown are labels representing values for respective first and second counters502, labels representing values for respective threshold levels504, identifiers for respective flags506and the flag state508of each flag. In the present example embodiment, the flag state508of each flag is set based on whether or not the values for respective counters502meet or exceed the values for corresponding threshold levels504.

For example, the flag state508of flag FLA for domain TJA is currently unset because first counter value CA1 does not meet or exceed corresponding first threshold level value L1 and second counter value CA2 does not meet or exceed corresponding second threshold level value LA2. However, the flag state508of flag FLB for domain TJB is currently set because first counter value CB1 meets or exceeds corresponding first threshold level value L1 or second counter value CB2 meets or exceed corresponding second threshold level value LB2. The flag state508of flag FLC for domain TJC is currently unset because first counter value CC1 does not meet or exceed corresponding first threshold level value LC1 and second counter value CC2 does not meet or exceed corresponding second threshold level value LC2. As the method300proceeds, datasets for domain TJA, domain TJB and domain TJC are processed and the values of the corresponding counters502may change as a result. Thus, the flag state508for each domain may change accordingly as each of the respective threshold levels504are met or exceeded. There may be fewer or additional domains in various embodiments based on the various domains associated with the datasets being processed.

FIG.6is a flowchart for illustrating a sample method600for updating a counter responsive to and based on a parsed base value of a subsequently received dataset that is useful in the method300ofFIG.3, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

At602, the OSP198receives a subsequent dataset associated with the domain on behalf of the primary entity. The subsequent dataset includes data regarding a follow-up relationship instance associated with the primary entity reversing the first relationship instance.

At604, the OSP198decrements the first counter responsive to receiving the subsequent dataset.

At606, the OSP198sets the flag status to false if the first counter no longer meets or exceeds the first threshold.

At608, the OSP198updates the second counter responsive to and based on a parsed base value of the subsequent dataset. The updating includes subtracting an amount from the second counter based on the parsed base value of the subsequent dataset.

At610, the OSP198sets the flag status to false if the second counter no longer meets or exceeds the second threshold.

FIG.7is a flowchart for illustrating another sample method700for automatically producing a resource based on a threshold being crossed, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

At702, the OSP198receives a dataset on behalf of a primary entity. The dataset includes data regarding a relationship instance associated with the primary entity.

At704, the OSP198determines a domain associated with the relationship instance.

At706, the OSP198parses from the dataset a base value associated with the dataset.

At708, the OSP198looks up a first threshold associated with the domain and a second threshold associated with the domain.

At710, the OSP198accesses a first counter associated with the primary entity and the domain.

At712, the OSP198increments the first counter responsive to receiving the dataset.

At714, the OSP198accesses a second counter representing a present base value associated with the primary entity and the domain.

At716, the OSP198updates the second counter responsive to and based on the parsed base value.

At718, the OSP198determines if one or more of: the first counter meets or exceeds the first threshold and the second counter meets or exceeds the second threshold. If one or more of: the first counter meets or exceeds the first threshold and the second counter meets or exceeds the second threshold, then the method700proceeds to718. In neither the first counter meets or exceeds the first threshold nor the second counter meets or exceeds the second threshold, then the method700proceeds to726.

At726, the OSP198produces a resource having a zero value and that is associated with the relationship instance.

At720, the OSP198looks up a rate applicable to the dataset based on the domain.

At722, the OSP198produces, based on the rate and the parsed base value, a resource having a nonzero value and that is associated with the relationship instance.

At724, the OSP198transmits a notification regarding the resource associated with the relationship instance.

FIG.8is a flowchart for illustrating a sample method800for handling exemptions that may be is associated with a relationship instance in producing resources based on a threshold being crossed that is useful in the method700ofFIG.7, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

At802, the OSP198determines whether or not one or more digital rules about relationship instances associated with the domain indicate to not count the relationship instance for purposes of determining whether the first counter meets or exceeds the first threshold. For example, one or more digital rules may indicate to not count the relationship instance in cases where an exemption is associated with the relationship instance.

At804, the OSP198determines whether or not an exemption is associated with the relationship instance.

At806, the OSP198increments the first counter based on a determination that there is not an exemption associated with the relationship instance.

FIG.9is a block diagram illustrating components of an exemplary computer system according to some exemplary embodiments, which may read instructions from a machine-readable medium (e.g., a non-transitory computer-readable medium) and perform any one or more of the processes, methods, and/or functionality discussed herein, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

In the present example,FIG.9is a block diagram illustrating components of a sample computer system1090and a sample computer system995according to some exemplary embodiments, which may read instructions from a machine-readable medium (e.g., a non-transitory computer-readable medium) and perform any one or more of the processes, methods, and/or functionality discussed herein. The computer system995may be a server, while the computer system1090may be a personal device, such as a personal computer, a desktop computer, a personal computing device such as a laptop computer, a tablet computer, a mobile phone, and so on. Either type may be used for the computer system195and190ofFIG.1, a computer system that is part of secondary entity196and/or a computer system that is part of any entity or system shown in any of the Figures of the present disclosure.

The computer system995and the computer system1090have similarities, whichFIG.8exploits for purposes of economy in this document. It will be understood, however, that a component in the computer system995may be implemented differently than the same component in the computer system1090. For instance, a memory in a server may be larger than a memory in a personal computer, and so on. Similarly, custom application programs974that implement embodiments may be different, and so on.

The computer system995includes one or more processors994. The processor(s)894are one or more physical circuits that manipulate physical quantities representing data values. The manipulation can be according to control signals, which can be known as commands, op codes, machine code, etc. The manipulation can produce corresponding output signals that are applied to operate a machine. As such, one or more processors894may, for example, include a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), a Field-Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), any combination of these, and so on. A processor may further be a multi-core processor having two or more independent processors that execute instructions. Such independent processors are sometimes called “cores”.

A hardware component such as a processor may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations. For example, a hardware component may include software executed by a general-purpose processor or another type of programmable processor. Once configured by such software, hardware components become specific machines, or specific components of a machine, uniquely tailored to perform the configured functions and are no longer general-purpose processors. It will be appreciated that the decision to implement a hardware component mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

As used herein, a “component” may refer to a device, physical entity or logic having boundaries defined by function or subroutine calls, branch points, Application Programming Interfaces (APIs), or other technologies that provide for the partitioning or modularization of particular processing or control functions. Components may be combined via their interfaces with other components to carry out a machine process. A component may be a packaged functional hardware unit designed for use with other components and a part of a program that usually performs a particular function of related functions. Components may constitute either software components (e.g., code embodied on a machine-readable medium) or hardware components. The hardware components depicted in the computer system995, or the computer system890, are not intended to be exhaustive. Rather, they are representative, for highlighting essential components that can be used with embodiments.

The computer system995also includes a system bus812that is coupled to the processor(s)994. The system bus912can be used by the processor(s)994to control and/or communicate with other components of the computer system995.

The computer system995additionally includes a network interface919that is coupled to system bus912. Network interface919can be used to access a communications network, such as the network188. Network interface919can be implemented by a hardware network interface, such as a Network Interface Card (NIC), wireless communication components, cellular communication components, Near Field Communication (NFC) components, 5G cellular wireless interfaces, transceivers, and antennas, Bluetooth® components such as Bluetooth® Low Energy, Wi-Fi® components, etc. Of course, such a hardware network interface may have its own software, and so on.

The computer system995also includes various memory components. These memory components include memory components shown separately in the computer system995, plus cache memory within the processor(s)994. Accordingly, these memory components are examples of non-transitory machine-readable media. The memory components shown separately in the computer system995are variously coupled, directly or indirectly, with the processor(s)894. The coupling in this example is via the system bus912.

Instructions for performing any of the methods or functions described in this document may be stored, completely or partially, within the memory components of the computer system995, etc. Therefore, one or more of these non-transitory computer-readable media can be configured to store instructions which, when executed by one or more processors994of a host computer system such as the computer system895or the computer system890, can cause the host computer system to perform operations according to embodiments. The instructions may be implemented by computer program code for carrying out operations for aspects of this document. The computer program code may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk or the like, and/or conventional procedural programming languages, such as the “C” programming language or similar programming languages such as C++, C Sharp, etc.

The memory components of the computer system995include a non-volatile hard drive933. The computer system995further includes a hard drive interface932that is coupled to the hard drive933and to the system bus912.

The memory components of the computer system995include a system memory938. The system memory938includes volatile memory including, but not limited to, cache memory, registers and buffers. In embodiments, data from the hard drive433populates registers of the volatile memory of the system memory938.

In some embodiments, the system memory938has a software architecture that uses a stack of layers, with each layer providing a particular functionality. In this example the layers include, starting from the bottom, an Operating System (OS)950, libraries960, frameworks/middleware968and application programs970, which are also known as applications970. Other software architectures may include less, more or different layers. For example, a presentation layer may also be included. For another example, some mobile or special purpose operating systems may not provide a frameworks/middleware968.

The OS950may manage hardware resources and provide common services. The libraries960provide a common infrastructure that is used by the applications970and/or other components and/or layers. The libraries960provide functionality that allows other software components to perform tasks more easily than if they interfaced directly with the specific underlying functionality of the OS950. The libraries960may include system libraries961, such as a C standard library. The system libraries961may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, and the like.

In addition, the libraries960may include API libraries962and other libraries963, such as for SDKs. The API libraries962may include media libraries, such as libraries to support presentation and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG. The API libraries962may also include graphics libraries, for instance an OpenGL framework that may be used to render 2D and 3D in a graphic content on the screen991. The API libraries962may further include database libraries, for instance SQLite, which may support various relational database functions. The API libraries962may additionally include web libraries, for instance WebKit, which may support web browsing functionality, and also libraries for applications970.

The frameworks/middleware968may provide a higher-level common infrastructure that may be used by the applications970and/or other software components/modules. For example, the frameworks/middleware968may provide various Graphic User Interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks/middleware968may provide a broad spectrum of other APIs that may be used by the applications970and/or other software components/modules, some of which may be specific to the OS950or to a platform.

The application programs970are also known more simply as applications and apps. One such app is a browser971, which is a software that can permit the user1092to access other devices in the internet, for example while using a Graphic User Interface (GUI). The browser971includes program modules and instructions that enable the computer system995to exchange network messages with a network, for example using Hypertext Transfer Protocol (HTTP) messaging.

The application programs970may include one or more custom applications974, made according to embodiments. These can be made so as to cause their host computer to perform operations according to embodiments disclosed herein. Of course, when implemented by software, operations according to embodiments disclosed herein may be implemented much faster than may be implemented by a human mind; for example, tens or hundreds of such operations may be performed per second according to embodiments, which is much faster than a human mind can do.

Other such applications970may include Enterprise Resource Planning (ERP) application, accounting applications, financial applications, accounting applications, payment systems applications, database and office applications, contacts application, a word processing application, a location application, a media application, a messaging application, and so on. Applications970may be developed for the Windows' operating system, and/or by using the ANDROID™ or IOS™ Software Development Kit (SDK) by an entity other than the vendor of the particular platform, and may be mobile software running on a mobile operating system such as IOS™, ANDROID™, WINDOWS® Phone, or other mobile operating systems. The applications970may use built-in functions of the OS950, of the libraries460, and of the frameworks/middleware968to create user interfaces for the user1092to interact with.

The computer system995moreover includes a bus bridge920coupled to the system bus912. The computer system995furthermore includes an input/output (I/O) bus921coupled to the bus bridge920. The computer system995also includes an I/O interface922coupled to the I/O bus921.

For being accessed, the computer system995also includes one or more Universal Serial Bus (USB) ports929. These can be coupled to the I/O interface922. The computer system995further includes a media tray926, which may include storage devices such as CD-ROM drives, multi-media interfaces, and so on.

The computer system990may include many components similar to those of the computer system995, as seen inFIG.9. In addition, a number of the application programs may be more suitable for the computer system990than for the computer system995.

The computer system990further includes peripheral input/output (I/O) devices for being accessed by a user192more routinely. As such, the computer system990includes a screen991and a video adapter928to drive and/or support the screen991. The video adapter928is coupled to the system bus912.

The computer system990also includes a keyboard923, mouse924, and a printer925. In this example, the keyboard923, the mouse924, and the printer925are directly coupled to the I/O interface922. Sometimes this coupling is wireless or may be via the USB ports929.

In this context, “machine-readable medium” refers to a component, device or other tangible media able to store instructions and data temporarily or permanently and may include, but is not be limited to: a thumb drive, a hard disk, random-access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, an Erasable Programmable Read-Only Memory (EPROM), an optical fiber, a portable digital versatile disc (DVD), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The machine that would read such a medium includes one or more processors994.

The term “machine-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) able to store instructions that a machine such as a processor can store, erase, or read. The term “machine-readable medium” shall also be taken to include any medium, or combination of multiple media, that is capable of storing instructions (e.g., code) for execution by a machine, such that the instructions, when executed by one or more processors of the machine, cause the machine to perform any one or more of the methods described herein. Accordingly, instructions transform a general or otherwise generic, non-programmed machine into a specialized particular machine programmed to carry out the described and illustrated functions in the manner described.

A computer readable signal traveling from, to, and via these components may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Operational Examples—Use Cases

The above-mentioned embodiments have one or more uses. Aspects presented below may be implemented as was described above for similar aspects. (Some, but not all, of these aspects have even similar reference numerals.)FIG.10is a diagram of sample aspects for describing operational examples and use cases of embodiments, according to embodiments of the present disclosure.

As a sample use case, statutes, tax rules, and rates change often, and new tax rules and tax types are continuously added. The OSP1098researches the underlying statutes and tax rules and guidance issued by the tax authorities1080, uses them to generate or obtain digital tax rules1070to compute tax obligations (also referred to herein as tax liabilities) for clients, such as seller1093, and makes the research available to all its clients. In addition, the OSP1098will keep enhancing its coverage of transaction compliance scenarios by enhancing its content and by building logic to determine increasing numbers of different types of compliance liabilities (e.g. tax types) required to be collected and paid to governing authorities, such as tax authorities1080. Clients trust the OSP1098for compliance and may expect the OSP1098to take an increasing amount of compliance burden away from their shoulders. However, with more than 10,000 tax jurisdictions in USA alone, it is a mammoth task to stay on top of these changes. For example, different tax jurisdictions have different rules for when a seller is required to collect and remit sales tax. A tax authority such as a state or even a city may set its own economic nexus rules for when a business is considered to be “engaged in business” with it, and therefore that business is subject to registration and collection of sales taxes. These nexus rules are often based on thresholds indicating a total number of sales transactions and/or a total monetary value of all sales in a given time period. It is a technical challenge for a business, such as seller1093, to constantly ascertain whether it meets these nexus different requirements in different tax jurisdictions in real time as transactions occur given the everchanging amount of sales in various different tax jurisdictions for the business in various time periods.

Thus, embodiments of OSP1098enable the option for the seller1093to choose/set in advance via an automatic collection of sales tax option selection1040for the tax engine1083of the OSP1098to detect exactly when an economic nexus threshold is crossed based on digital tax rules1070. In embodiments, the OSP1098processes incoming transaction data represented by dataset1035of sellers, such as seller1098and counts them towards the economic nexus thresholds indicated by the digital tax rules1070. Upon detecting when an economic nexus threshold is crossed based, the OSP108may automatically start determining the tax obligation1079for transactions and start assessing sales tax immediately, and/or automatically initiate registration for the seller1098with one or more tax authorities in the set of tax authorities1080, and/or send notifications, such as notification1079, regarding the economic nexus threshold being crossed. The OSP1098can do all this always, or only upon prior request by the seller1098, e.g., per advance settings, at time of on-boarding for services with the OSP1098or later.

Accordingly, at the exact time that the seller1098will start owing sales tax, such will start being collected for them by the OSP1098. The seller1098will not be distracted by a notification of upcoming nexus, nor will they be burdened in having to do anything about the notification. Using the system described herein, the seller1098will not find out late about crossing the threshold, with the heartache about passing up income, or have misguided temptations about flouting their obligations.

The OSP1098can further detect when economic nexus ends by applying digital tax rules1070. Upon so detecting, the OSP1098can send notifications, such as notification1036, and/or automatically stop assessing sales tax, and/or automatically initiate registration for the seller1093with the department of revenue of the applicable tax authority, such as tax authority1081. The OSP1098can do this always, or only upon prior request by the seller1098, e.g. per advance settings via an automatic collection of sales tax option selection1040, at time of on-boarding or later.

In deciding for which jurisdictions to count for economic nexus, the OSP1098may determine whether nexus has been reached by some other way, and start collecting sales tax there anyway. Upon on-boarding, and optionally periodically thereafter, the seller1093may “study”/evaluate where they have nexus already.

In the counting the transactions towards the threshold, the OSP1093may further adjust: not counting sales for which there are exemption certificates, if the digital rules associated with the applicable tax authority1081indicates they do not count them, and/or not incrementing a counter towards the economic nexus threshold for exempt sales transactions, if the digital rules associated with the applicable tax authority1081indicates they do not count them.

In some embodiments, the above is performed, and based on monitoring of transaction volume and total value for seller1093, sales tax starts being owed starting with a particular transaction, or sales tax may also be owed on a number of previous transactions. For example, sales tax may start being owed from the 201st transaction on, alone, or from the 201st transaction on, plus on the first200transactions. This can be looked up by the digital rules1070rules (yes/no to the first200), and notification1079may be sent regarding the tax obligation1079. The OSP1098looks up stored rules of the tax jurisdiction (e.g., of tax authority1082). These rules include the economic nexus thresholds.

In some close cases, in which the seller1093is very close to the economic threshold, the seller1093may stop selling the item for the remainder of the relevant time period, and re-starts. For example, using information in notification1036, the seller may decide, based on sales velocity, whether it is worth continuing in the sales period, etc. This calculation whether it is worth continuing in the sales period, etc., may be made by the OSP1098based on applicable settings received from the seller1093and the digital rules1070.

Operational examples and sample use cases are possible where the attribute of an entity in a dataset is any one of: the entity's name; type of entity; a physical location such as an address; a contact information element; transactions of the entity; an identifier of a specific source of revenue received for a transaction of the entity; characteristics of transactions of the entity; licensure and/or or registration of the entity and/or products or services the entity produces, sells, stores and/or transfers; products or services produced, sold, stored and/or transferred by the entity; types of products or services produced, sold, stored and/or transferred by the entity; a location to which products are sent, shipped or transferred; a location from which products are received; a location of a property owned by the entity; a location of a property owned by the entity within a particular region of other domain; an affiliation; a characterization of another entity; a characterization by another entity; an association or relationship with another entity (general or specific instances); an asset of the entity; a declaration by or on behalf of the entity; and so on. Different resources may be produced in such instances, and so on.

In particular,FIG.10is diagram for an operational example and use case where the resource1079includes a tax obligation of a primary entity, such as seller of goods or services1093and/or a secondary entity, such as buyer1096of goods or services, due to a transaction1097. It will be recognized that aspects ofFIG.9have similarities with aspects ofFIG.1. Portions of such aspects may be implemented as described for analogous aspects ofFIG.1. In particular, a thick line915separatesFIG.9, although not completely or rigorously, into a top portion and a bottom portion. Above the line915the emphasis is mostly on entities, components, their relationships, and their interactions, while below it the emphasis is mostly processing of data that takes place often within one or more of the components above the line915. Above the line915, a computer system1095is shown, which is used to help clients, such as a seller1093and an associated user1092, with tax compliance. Further in this example, the computer system1095is part of an OSP1098that is implemented as a Software as a Service (SaaS) provider, for being accessed by the user1092online. Alternately, the functionality of the computer system1095may be provided locally to a user.

The user1092may be standalone. The user1092may use a computer system1090that has a screen1091. In embodiments, the user1092and the computer system1090are considered part of the seller1093, which is also known as entity1093. The seller1093can be a business, such as a seller of items, a reseller, and so on. The user1092can be an employee, a contractor, or otherwise an agent of the entity1093. In use cases, the seller1093and the buyer1096are performing the buy-sell transaction1097. The transaction1097will have data that is known to the seller1093, similarly with what was described by the relationship instance197ofFIG.1B.

In a number of instances, the user1092and the seller1093use software applications to manage their business activities, such as sales, resource management, production, inventory management, delivery, billing, and so on. The user1092and/or the seller1093may further use accounting applications to manage purchase orders, reservations, bookings, sales invoices, refunds, payroll, accounts payable, accounts receivable, and so on. Such software applications, and more, may be used locally by the user1092or from an Online Processing Facility (OPF)1089that has been engaged for this purpose by the user1092, and/or the seller. In such use cases, the OPF1089can be a Mobile Payments system, a Point of Sale (POS) system, an Accounting application, an Enterprise Resource Planning (ERP) provider, an e-commerce provider, an electronic marketplace, a Seller Relationship Management (CRM) system, and so on.

Businesses have tax obligations to various tax authorities of respective domains (e.g., respective tax jurisdictions). A first challenge is in making the related determinations. Tax-related determinations, made for the ultimate purpose of tax compliance, are challenging because the underlying statutes and tax rules and guidance issued by the tax authorities are very complex. There are various types of tax, such as sales tax, use tax, excise tax, value-added tax, lodging tax, and issues about cross-border taxation including customs and duties, and many more. Some types of tax are industry specific. Each type of tax has its own set of rules. Additionally, statutes, tax rules, and rates change often, and new tax rules are continuously added. Compliance becomes further complicated when a taxing authority, such as tax authority1081or tax authority1082promulgates new tax types of which the seller1093is presently unaware.

Tax jurisdictions are defined mainly by geography. Businesses have tax obligations to various tax authorities within the respective tax jurisdictions. There are various tax authorities, such as that of a country, of a state, of a municipality, of a local district such as a local transit district and so on. So, for example, when a business sells items in transactions that can be taxed by a tax authority, the business may have the tax obligations to the tax authority. These obligations include requiring the business to: a) register itself with the tax authority's taxing agency, b) set up internal processes for collecting sales tax in accordance with the sales tax rules of the tax authority, c) maintain records of the sales transactions and of the collected sales tax in the event of a subsequent audit by the taxing agency, d) periodically prepare a form (“tax return”) that includes an accurate determination of the amount of the money owed to the tax authority as sales tax because of the sales transactions, e) file the tax return with the tax authority by a deadline determined by the tax authority, and f) pay (“remit”) that amount of money to the tax authority. In such cases, the filing and payment frequency and deadlines are determined by the tax authority.

A technical problem for businesses is that the above-mentioned software applications generally cannot provide tax information that is accurate and current enough for the businesses to be tax compliant with all the relevant tax authorities. The lack of accuracy may manifest itself as errors in the amounts determined to be owed as taxes to the various tax authorities, and it is plain not good to have such errors. For example, businesses that sell products and services have risks whether they over-estimate or under-estimate the sales tax due from a sale transaction. On the one hand, if a seller over-estimates the sales tax due, then the seller collects more sales tax from the buyers than was due. Of course, the seller may not keep this surplus sales tax, but instead must pay it to the tax authorities—if they cannot refund it to the buyers. If a buyer later learns that they paid unnecessarily more sales tax than was due, the seller risks at least harm to their reputation. Sometimes the buyer will have the option to ask the state for a refund of the excess tax by sending an explanation and the receipt, but that is often not done as it is too cumbersome. On the other hand, if a seller under-estimates the sales tax due, then the seller collects less sales tax from the buyers, and therefore pays less sales tax to the authorities than was actually due. That is an underpayment of sales tax that will likely be discovered later, if the tax authority audits the seller. Then the seller will be required to pay the difference, plus fines and/or late fees, because ignorance of the law is not an excuse. Further, one should note that sales taxes are considered trust-fund taxes, meaning that the management of a company can be held personally liable for the unpaid sales tax.

For sales in particular, making correct determinations for sales and use tax is even more difficult. There are a number of factors that contribute to its complexity.

First, some state and local tax authorities have origin-based tax rules, while others have destination-based tax rules. Accordingly, a sales tax may be charged from the seller's location or from the buyer's location.

Second, the various tax authorities assess different, i.e. non-uniform, percentage rates of the sales price as sales tax, for the purchase and sale of items that involve their various tax jurisdictions. These tax jurisdictions include various states, counties, cities, municipalities, special taxing jurisdictions, and so on. In fact, there are over 10,000 different tax jurisdictions in the US, with many partially overlapping.

Third, in some instances no sales tax is due at all because of the type of item sold. For example, in 2018 selling cowboy boots was exempt from sales tax in Texas, but not in New York. This non-uniformity gives rise to numerous individual taxability rules related to various products and services across different tax jurisdictions.

Fourth, in some instances no sales tax is due at all because of who the individual buyer is. For example, certain entities are exempt from paying sales tax on their purchases, so long as they properly create and sign an exemption certificate and give it to the seller for each purchase made. Entities that are entitled to such exemptions may include wholesalers, resellers, non-profit charities, educational institutions, etc. Of course, who can be exempt is not exactly the same in each tax jurisdiction. And, even when an entity is entitled to be exempt, different tax jurisdictions may have different requirements for the certificate of exemption to be issued and/or remain valid.

Fifth, it can be difficult to determine which tax authorities a seller owes sales tax to. A seller may start with tax jurisdictions that it has a physical presence in, such as a main office, a distribution center or warehouse, an employee working remotely, and so on. Such ties with a tax jurisdiction establish the so-called physical nexus. However, a tax authority such as a state or even a city may set its own nexus rules for when a business is considered to be “engaged in business” with it, and therefore that business is subject to registration and collection of sales taxes. These nexus rules may include different types of nexus, such as affiliate nexus, click-through nexus, cookie nexus, economic nexus with thresholds, and so on. For instance, due to economic nexus, a remote seller may owe sales tax for sales made in the jurisdiction that are a) above a set threshold volume, and/or b) above a set threshold number of sales transactions.

To help with such complex determinations and solve such technical problems, the computer system1095may be specialized device for tax compliance as disclosed herein. The computer system1095may have one or more processors and memory, for example, as was described for the computer system195ofFIG.1. The computer system1095thus implements a tax engine1083to automatically start determining sales tax obligations on transactions associated with a particular jurisdiction for sellers based on an economic threshold being crossed for a particular tax jurisdiction. The tax engine1083can be as described for the service engine183.

The computer system1095may further store locally entity data, i.e. data of user1092, of entity1093, any of which/whom may be a seller, and/or a seller or a buyer in a sales transaction in various embodiments. The entity data may include profile data of the seller and transaction data from which a determination of a tax obligation is desired. In the online implementation ofFIG.9, the OSP1098has a database1094for storing the entity data. This entity data may be inputted by the user1092, and/or caused to be downloaded or uploaded by the user1092from the computer system1090or from the OPF1089, or extracted from the computer system1090or from the OPF1089, and so on. In other implementations, a simpler memory configuration may suffice for storing the entity data.

Digital tax content1086is further implemented within the OSP1098. The digital tax content1086can be a utility that stores digital tax rules1070for use by the tax engine1083. As part of managing the digital tax content1086, there may be continuous updates of the digital tax rules, by inputs gleaned from a set980of different tax authorities1081,1082, . . . . Updating may be performed by humans, or by computers, and so on. As mentioned above, the number of the different tax authorities in the set1080may be very large and the future digital tax rules resulting from tax regulations promulgated by such tax authorities in the set980, once recognized and stored by the OSP1098, may be used to determine whether economic nexus thresholds have been met or exceeded and compute such tax obligations based on an automatic collection of sales tax option selection1040received from the seller1093.

For a specific determination of a tax obligation, the computer system1095may receive one or more datasets. A sample received dataset1035is shown just below line1015, which can be similar to what was described for the dataset135ofFIG.1. In this example, the computer system1090transmits a request1034that includes a payload1034, and the dataset1035is received by the computer system1095parsing the received payload1034. In this example, the single payload1034encodes the entire dataset1035, but that is not required, as mentioned earlier. The computer system1090may also transmit an automatic collection of sales tax option selection1040which indicates to the OSP1098that the seller1093has selected to have the OSP1098trigger the tax engine1083to automatically start computation and/or collection of sales taxes upon one or more economic thresholds being crossed.

In this example, the dataset1035has been received because it is desired to determine any tax obligations arising from the buy-sell transaction1097. As such, the sample received dataset1035has values that characterize attributes of the buy-sell transaction1097, as indicated by an arrow1099. (It should be noted that the arrow1099describes a correspondence, but not the journey of the data of the buy-sell transaction1097in becoming the received dataset1035.) Accordingly, in this example the sample received dataset1035has a value ID for an identity of the dataset1035and/or the transaction1097. The dataset1035also has a value PE for the name of the seller1093or the user1092, which can be the seller1093making sales transactions, some online. The dataset1035further has a value PD for relevant data of the seller1093the user1092, or the transaction, such as calendar year of the transaction, an address, place(s) of business, prior nexus determinations with various tax jurisdictions, and so on. The dataset1035also has a value SE for the name of the buyer1096. The dataset1035further has a value SD for relevant data of the buyer1096, entity-driven exemption status, and so on. The dataset1035has a value B2 for the sale price of the item sold.

The dataset1035may fewer values or have additional values, as indicated by the dot-dot-dot in the dataset1035. These values may characterize further attributes, such as characteristics of the item being sold, data identifying of or otherwise relating to a license or registration required for the transaction, a date and possibly also time of the transaction1097, and so on.

The digital tax rules970have been created so as to accommodate tax rules that the set980of different tax authorities981,1082. . . promulgate within the boundaries of their tax jurisdictions. InFIG.5, five sample digital tax rules are shown, namely T_RULE21072, T_RULE31073, T_RULE51075, T_RULE61076and T_RULE71077. Additional digital tax rules1070are suggested by the vertical dot-dot-dots. Similarly withFIG.1, some of these digital tax rules may be digital main rules that determine the tax obligation1079, while others can be digital precedence rules that indicate economic thresholds, determine when economic thresholds are crossed or which of the digital main rules is to be applied in the event of conflict. In some use cases, digital main tax rules may be about a sales tax or use tax being owed due to the transaction1097at a certain percentage of the purchase price. Digital precedence rules may be digital tax rules that determine whether particular digital tax rules are to be applied for origin-based or destination-based jurisdictions, how to override for diverse taxability of individual items, for temporary tax holidays, for exemptions from having to pay sales tax based on who the buyer is, and also based on nexus, and so on. In the present example, digital precedence rules may be digital tax rules that determine whether particular digital tax rules are to be applied based on whether economic threshold has been met or exceeded for one or more tax jurisdictions associated with a transaction, such as transaction1097, and/or based on whether or not the seller has selected to have the OSP1098automatically produce one or more tax obligations for the dataset according to whether such economic thresholds have been met or exceeded.

Similarly withFIG.2, these digital tax rules970can be implemented or organized in different ways. In some use cases they can be organized with conditions and consequents, such as was described earlier in this document. Such conditions may relate to geographical boundaries, sources of revenue, effective dates, and so on, for determining where and when a digital tax rule or tax rate is to be applied. These conditions may be expressed as logical conditions with ranges, dates, other data, and so on. Values of the dataset1035can be iteratively tested against these logical conditions according to arrows1071. In such cases, the consequents may indicate one or more economic thresholds and tax obligations, such as to indicate different types of taxes that are due, rules, rates, exemption requirements, reporting requirements, remittance requirements, etc.

In this example, a certain digital tax rule T_RULE51075is shown as identified and used, which is indicated also by the beginning of an arrow1078. Identifying may be performed responsive to the values of the dataset1035, which are shown as considered for digital tax rules1070by arrows1071. For example, it can be recognized that a condition of the digital tax rule T_RULE51075is met by one or more of the values of the dataset1035.

As such, the computer system1095may produce the tax obligation1079and tax return document, which is akin to producing the resource179ofFIG.1. The computer system1095may also file or otherwise send (or cause to be filed or sent) the tax return document to one or more of the applicable tax authorities in the set of tax authorities980via network188. The tax obligation1079can be produced by the computer system1095applying the certain digital tax rule T_RULE51075, as indicated by the arrow978. In this example, the consequent of the identified certain digital tax rule T_RULE51075may specify that an economic threshold has been met or exceeded and thus a sales tax is due for an item, the amount is to be determined by a multiplication of the sale price of the value B2 by a specific rate, the tax return form that needs to be prepared and filed, a date by which it needs to be filed, and so on.

The computer system1095may then cause a notification1036to be transmitted. The notification1036can be about an aspect of the tax obligation1079, similarly with the notification136ofFIG.1. In the example ofFIG.10, the notification1036is caused to be transmitted by the computer system1095as an answer to the received dataset1035. The notification1036can be about an aspect of the tax obligation1079. In particular, the notification1036may inform about the aspect of the tax obligation1079, namely that it has been determined, where it can be found, what it is, or at least a portion or a statistic of its content, and so on.

The notification1036can be transmitted to one of an output device and another device that can be the remote device, from which the dataset1035was received. The output device may be the screen of a local user or a remote user. The notification1036may thus cause a desired image to appear on the screen, such as within a Graphical User Interface (GUI) and so on. The other device may be a remote device, as in this example. In particular, the computer system1095causes the notification1036to be communicated by being encoded as a payload1037, which is carried by a response1087. The response987may be transmitted via the network188responsive to the received request1084. The response987may be transmitted to the computer system1090, or to OPF1089, and so on. As such, the other device can be the computer system1090, a device of the OPF1089, or the screen1091of the user1092, and so on. In this example the single payload937encodes the entire notification1036, but that is not required, similarly with what is written above about encoding datasets in payloads. Along with the aspect of the tax obligation1079, it is advantageous to embed in the payload1037the ID value, one or more values of the dataset1035and/or one or more of the digital tax rules1070used to compute the tax obligation1079. This will help the recipient correlate the response1087to the request984, and therefore match the received aspect of the tax obligation1079as the answer to the received dataset1035.

The OSP1098also enables seller1093to have the OSP1098to automatically start producing one more tax obligations for the dataset1035when an economic threshold is met or crossed for the jurisdiction associated with the dataset1035based on previous transactions of the seller1093associated with that tax jurisdiction. The OSP1098may receive a first input, such as automatic collection of sales tax option selection1040as part of request984, indicating whether or not the seller1093has selected the first special tax option. In some embodiments, this automatic collection of sales tax option selection1040may be received with, in conjunction with, or as part of the payload934. In some embodiments, the request184may include the dataset1035. However, in the present embodiment, the automatic collection of sales tax option selection1040is received before the dataset1035. In various embodiments, the automatic collection of sales tax option selection1040may be received by the OSP1098during or after the initial onboarding or subscription of the seller1093to the services of the OSP1098. In some embodiments, the automatic collection of sales tax option selection1040having been received by the OSP1098is a condition that must be met that is indicated by a digital precedence rule, such as T_RULE3173, for rule T_RULE6976to be applied.

FIG.11is a block diagram showing sample components of a system1100for automatically starting transaction tax computations and enabling collection of transaction tax for transactions upon a threshold for purposes of establishing economic nexus in a particular tax jurisdiction being crossed, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

In some embodiments, the OSP1198, which may be an example of OSP1098ofFIG.10or OSP198ofFIG.1, counts sales transactions towards determining whether an economic threshold of tax authority1180has been met or exceeded that other OSPs, such as third party OSP1106, have processed separately. For example, in various embodiments the OSP1198totals the sales transactions of seller1192the OSP1198has counted itself and the sales transactions the third party OSP1106has processed separately. The OSP1198then uses this total to determine whether one or more economic thresholds have been met or exceeded. The third party OSP1106may be, or may be in operable communication with, a platform of the seller1192itself, a point of sale (POS) system1102of the seller itself, etc.

The diagram of the system1100illustrates how a seller1192may initially set up the OSP1198by supplying the necessary documents and providing access and consent to have the OSP1198pull seller-related information from a different third party OSP1106. For example, the OSP1198may present the authorization to the third party OSP1106and subscribes to receive the seller-related transaction data originating from the POS system1102and/or the transaction store1108, or uses the provided access to pull the information periodically from the third party OSP1106and/or the POS system1102. The transaction information may be pulled from the third party OSP1106and/or the POS system1102as requested, upon a particular number or total value of transactions being processed, and/or according to various other triggers or conditions. The third party OSP1106provides the seller transaction information as per the presented authorization and consent.

In an example embodiment, after the initial setup, the seller owned or leased POS equipment of the POS system1102transmits transactions of the seller1192automatically to the OSP1198and/or third party OSP1106. The seller1192may also manually submit the transaction data by pulling it from secondary transactional stores, such as transaction store1108. The OSP1198is provided a complete and comprehensive record of all seller-related transactions and, thus, is enabled to proceed with the calculation of whether the economic nexus thresholds have been met or exceeded. At this point, the documented flow of the method1200inFIG.12may be performed.

In various embodiments, the OSP1198may automatically register or deregister seller1192with tax authority1180for collection of and remitting transactions taxes in response to a determination by the OSP1198of whether or not the transactions of the seller1192meet or exceed an economic threshold of the tax authority1180. The tax authority1180may also issue licenses regarding sales of goods or services and the collection of taxes therefor. The registration of the seller1192, deregistration of the seller1192and issuing of licenses may be performed automatically, such as via network API calls between the OSP1198and the tax authority1180or by manually triggering sending of electronic documents and communications between the OSP1198and the tax authority1180to do so.

In various embodiments, the communications and data transfers between, and services provided by or to, the various entities inFIG.11, may be performed via network API calls, such as over network188ofFIG.1andFIG.10.

FIG.12is a is a flowchart for illustrating a sample method1200for automatically starting transaction tax computations for transactions and enabling collection of transaction tax for transactions upon a threshold for purposes of establishing economic nexus in a particular tax jurisdiction being crossed, according to embodiments of the present disclosure, which is an improvement in automated computerized systems. For example, in various embodiments, the method1200may be performed by the OSP1198ofFIG.12, the OSP1098ofFIG.10and/or the OSP198ofFIG.1. In the present example, the method1200is performed by the OSP1198ofFIG.12.

At1202, the OSP1198has determined that an economic nexus in a particular tax jurisdiction has been not met. For example, this may be indicated by a flag being set to false.

At1204, the OSP1198determines whether or not the economic nexus in the particular tax jurisdiction has been established. For example, this may be by determining whether a threshold for purposes of establishing economic nexus in the particular tax jurisdiction has been met or exceeded. The threshold may indicate, for example, a minimum number of transactions over a particular time period and/or a minimum total value of transactions over the time period. If it is determined by the OSP1198that the economic nexus in the particular tax jurisdiction has been met, then the method1200proceeds to1206. If it is determined by the OSP1198that the economic nexus in the particular tax jurisdiction has not been established, then the method1200proceeds back to1202. The determination of whether or not the economic nexus in the particular tax jurisdiction has been established may be performed periodically, upon request of the seller1192, and/or on a per-transaction basis in real-time as each transaction occurs.

At1206, the OSP1198automatically registers seller1192with tax authority1180for purposes of collection of and remitting transactions taxes.

At1208, the OSP1198produces the applicable resource (e.g., computes the transaction tax obligation for the current transaction, the next transactions going forward and/or a previous number of transactions) and enables collection of the computed transaction tax obligation.

At1210the OSP determines that the economic nexus in the particular tax jurisdiction has been met. For example, this may be indicated by the OSP1198setting the flag to true.

At1212, the OSP1198determines whether or not the economic nexus in the particular tax jurisdiction has been dis-established. For example, this may be by determining whether a threshold for purposes of establishing economic nexus in the particular tax jurisdiction is no longer met or exceeded. If it is determined by the OSP1198that the economic nexus in the particular tax jurisdiction has been dis-established, then the method1200proceeds to1214. If it is determined by the OSP1198that the economic nexus in the particular tax jurisdiction has not been dis-established, then the method1200proceeds back to1210. The determination of whether or not the economic nexus in the particular tax jurisdiction has been dis-established may be performed periodically, upon request of the seller1192, and/or on a per-transaction basis in real-time as each transaction occurs.

At1214, the OSP1198automatically de-registers seller1192with tax authority1180for purposes of collection of and remitting transactions taxes.

At1208, the OSP1198disables collection of transaction tax for the current transaction and/or the next transactions going forward. The method1200then proceeds back to1202.

FIG.13is a listing1300of example pseudocode for a sample method for automatically starting transaction tax computations for transactions and enabling collection of transaction tax for transactions upon a threshold for purposes of establishing economic nexus in a particular tax jurisdiction being crossed, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

According to the listing1300of example pseudocode, a program executing according to the pseudocode initializes to zero a counter for the total number transactions of a seller that are associated with a particular domain (e.g., tax jurisdiction) and initializes to zero a counter for the total monetary amount of those transactions. As each dataset for a transaction is received, the program determines, based on the dataset, whether the transaction is associated with the particular domain. If it is not, it is discarded. If it is associated with the particular domain, the counters are updated accordingly.

After the counters are updated, the program checks whether or not the current values of the counters cross the applicable economic thresholds for the particular domain. If either of the thresholds have been crossed, then the program sets a flag to true indicating economic nexus has been established and imitates instructions to register the seller (if not already registered) with the applicable tax authority for collection of and remitting transactions taxes and to compute the applicable resource (e.g., transaction tax) for the transaction.

If neither of the thresholds have been crossed, then the program checks whether a new year has been started. Various different timeframes (months, quarters, fiscal or calendar years, etc.) may be used in different embodiments. If the program determines a new year has been started, the counters are initialized to zero and the next dataset for the next transaction is processed as above. Otherwise, the counters are not initialized to zero and the next dataset for the next transaction is processed as above.

FIG.14is a sample view of a User Interface (UI)1400in which an option is presented for a client to enable automatic collection of sales tax at about the time that the client's sales will be crossing applicable thresholds for economic nexus, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

Shown is UI1400presented on a screen1491of a device. For example, the screen1491may be screen1091of the computer system1090or other device of the seller1093or user1092ofFIG.10. Shown in UI1400an options that the user1092may select to electronically indicate to the OSP1098whether or not to automatically start collection of sales tax at about the time that the seller's sales will be crossing applicable thresholds for economic nexus as described herein. For example, UI1400may be presented to the user1092during the on-boarding of the seller to the OSP1098when subscribing to services of the OSP1098.

FIG.15is a sample view of a User Interface (UI)1500in which the client has selected an option to enable automatic collection of sales tax at about the time that the client's sales will be crossing applicable thresholds for economic nexus, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

Shown is UI1500presented on a screen1591of a device. For example, the screen1591may be screen1091of the computer system1090or other device of the seller1093or user1092ofFIG.10. In the present example embodiment, UI1500is presented after the user1092has selected the option presented in UI1400to enable automatic collection of sales tax and selected the “continue” button or link shown in UI1400. Presented in the UI1500is an option the user may then select to give consent to the OSP1098to change system settings to enable the OSP1098to automatically start collection of sales tax as described herein.

FIG.16is a sample view of a User Interface (UI)1600in which the client has selected an option to enable automatic collection of sales tax at about the time that the client's sales will be crossing applicable thresholds for economic nexus and further options are presented for the client regarding registration in tax jurisdictions in which the client's sales will be crossing applicable thresholds for economic nexus, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

Shown is UI1600presented on a screen1691of a device. For example, the screen1691may be screen1091of the computer system1090or other device of the seller1093or user1092ofFIG.10. In the present example embodiment, the user1092may indicate that upon the OSP1098detecting the seller1093crossing applicable thresholds for economic nexus, to have the OSP1098either automatically initiate the registering process for the seller1093, notify the seller1093(so the seller can register themselves), or to not notify the seller1093at all.

FIG.17is a sample view of a User Interface (UI)1700in which an option is presented for a client to automatically disable collection of sales tax in a particular tax jurisdiction based on the client's economic nexus ending in that tax jurisdiction, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

Shown is UI1700presented on a screen1791of a device, for example, after the user selects the “continue” button or link of UI1600. For example, the screen1791may be screen1091of the computer system1090or other device of the seller1093or user1092ofFIG.10. In the present example embodiment, the user1092may indicate that upon the OSP1098detecting the seller1093no longer meets the thresholds for economic nexus, whether or not to have the OSP1098automatically disable collection of sales tax at the right time for the seller1093.

FIG.18is a sample view of a User Interface (UI)1800in which the client as selected an option to automatically disable collection of sales tax in a particular tax jurisdiction based on the client's economic nexus ending in that tax jurisdiction and a further option is presented regarding de-registering the client in the particular tax jurisdiction, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

Shown is UI1800presented on a screen1891of a device, for example, after the user selects the “continue” button or link of UI1700. For example, the screen1791may be screen1091of the computer system1090or other device of the seller1093or user1092ofFIG.10. In the present example, the user1092may select an option to have the OSP1098either automatically initiate the de-registering process for the seller1093, just notify the seller1093(so the seller1093can de-register themselves), or not notify the seller1093at all regarding de-registering.

FIG.19illustrates an example of a plurality of extracted datasets1900, according to embodiments of the present disclosure, which is an improvement in automated computerized systems.

In the embodiment shown inFIG.19, each dataset represents and includes data corresponding to a transaction of the client entity, such as seller1093inFIG.10, which is a provider of goods or services, and a secondary entity (e.g., a recipient of the goods or services), such as buyer1096inFIG.10. Shown in extracted datasets1900are individual values for parameter value ID, which is an identifier of the dataset, parameter value DY, which is, in the present example use case, the calendar year in which the transaction occurred; parameter value BX, which is, in the present example use case, the amount of the transaction; and parameter value ST, which is, in the present example use case, the domain (e.g., state) associated with the transaction. In the present example, the extracted datasets1900are sorted (starting on the left, from bottom to top) by the parameter value DY, or calendar year of the transaction. In the present embodiment, this sorting may have been performed by the computer system1095of the OSP1098.

FIG.20illustrates the example datasets1900fromFIG.19that have been filtered according to various embodiments of the disclosure, which is an improvement in automated computerized systems.

In some embodiments, the sorting, grouping or otherwise filtering of the datasets of the client data in a particular manner enable or otherwise facilitate the client data to be processed by the OSP1098in order to apply one or more digital rules to the copied data to generate a determination regarding whether a threshold for purposes of establishing economic nexus in a particular tax jurisdiction has crossed. The OSP1098may then automatically start to compute and initiate collection of applicable transaction taxes for the client (and also register the client in the applicable tax jurisdiction for purposes of collecting and remitting transaction tax in that jurisdiction) in response to a determination that the threshold has been crossed. In the present example, the copied client data is filtered (e.g., by the OSP1098) such that the datasets are grouped or categorized by the parameter value DY (calendar year of the transaction) and the parameter value ST (domain associated with the transaction).

The datasets1900are shown filtered in such a manner within a matrix in which the horizontal axis2008of the matrix represents time in terms of the calendar year of the transaction represented by the dataset and the vertical axis2007of the matrix represents the domain (e.g., tax jurisdiction) associated with the transaction represented by the dataset. In some embodiments, there may be multiple domains associated with a particular dataset and thus there may be multiple matrices used. Thus, each cell of the matrix contains the datasets for transactions that occurred in a particular year and that are associated with a particular domain. For example, inFIG.20there is one cell that contains all the datasets representing all those transactions of the client entity that occurred in2020in the state of New Jersey (NJ). As shown inFIG.20, there are two datasets (representing two respective transactions) in that cell which meet that criteria. As another example, there is one cell that contains all the datasets representing all those transactions of the client entity that occurred in2019in the state of California (CA). As shown inFIG.20, there are three datasets (representing three respective transactions) in that cell.

In some embodiments, the matrix shown inFIG.20represents a data structure of the client data as generated, filtered and/or stored by the OSP1098, or may represent logical relationships between the datasets as a result of the filtering. In some embodiments, such filtering may be performed by a tax engine1083of the OSP1098. In some embodiments, the OSP1098may extrapolate from, or interpret the filtered datasets to detect, relevant trends, patterns or other information relevant to the client entity. For example, by filtering the datasets of the copied data, the OSP1098may detect a trend that the client entity's sales have flattened in Illinois (IL), and may be approaching falling below a threshold in IL for economic nexus, but the client entity is more recently getting into new markets California (CA), New York (NY) and New Jersey (NJ) and may be approaching crossing one or more thresholds for economic nexus one or more of those states.

FIG.21illustrates an example of application of rules to datasets according to various embodiments of the disclosure, which is an improvement in automated computerized systems.

The filtering of the datasets of the client data into cells, as described with respect toFIG.20, in which each cell contains the datasets for transactions that occurred in a particular year and that are associated with a particular domain, facilitate the client data to be processed by the OSP1098in order to apply one or more digital rules based on whether a nexus threshold has been met for particular domain in a particular calendar year. For example, such may be useful for a client entity or OSP1098to determine whether the client entity is subject to sales tax regulations for a particular domain and is obligated to collect and remit sales tax for particular domain, and then to trigger the OSP1098to automatically start to compute and initiate collection of applicable transaction taxes for the client, and also register the client in the applicable domain for purposes of collecting and remitting transaction tax in that domain). In the present example, the stored digital rules facilitate determining whether an economic nexus is established for purposes of remitting transaction tax in the certain domain (e.g., tax jurisdiction). However, different states have different thresholds for determining whether there is an economic nexus, which provides a problem for retailers in determining whether they are compliant with the tax rules in various jurisdictions, especially when the retailers have ever changing total revenue and numbers of transactions in various different domains (e.g., tax jurisdictions). Determining tax compliance under such circumstances for multiple retailers in various different jurisdictions according to the various different rules for the different tax jurisdictions, communicating such information to the retailers or other entities efficiently, computing tax obligations and electronically collecting the correct tax amount as transactions are occurring and rules are changing presents a technical problem in order to do so in a timely and efficient manner over computer networks and in a way that integrates well into existing technical environments in which tax assistance is provided. The present disclosure provides systems and methods that solve this technical problem by improving the speed, efficiency and accuracy of such specialized software platforms and computer networks.

For example, the digital rules applied by the OSP1098may be based on regulations regarding a monetary amount of sales that are associated with each of various tax jurisdictions (e.g., states) and/or a volume of sales transactions that are associated with each of various tax jurisdictions. In an embodiment, the regulation may indicate the client entity is obligated to collect and remit sales tax in a particular tax jurisdiction if a particular economic nexus is met. For example, this particular economic nexus may be that within a particular calendar year, the total number of transactions exceed a particular threshold and the sum of the transaction amounts of all those transactions in that calendar year exceed another threshold. Thus, the digital rule based on the regulation will test the datasets representing those transactions to determine whether the thresholds are met for those datasets.

In the present embodiment, the computer system of the OSP1098applies such a digital rule to each cell of the matrix ofFIG.20, as each cell contains datasets for a particular year and particular tax jurisdiction. In various embodiments, different digitals rule may be applied to different cells associated with different domains, as each domain (e.g., tax jurisdiction) may have different tax regulations on which the digital rules are based. For example, as shown inFIG.21, for each cell in the matrix ofFIG.20, the OSP1098calculates the sum of the transaction amounts (represented by parameter value BX in each dataset) of all the datasets in the cell, which represents the monetary amount of sales for the client entity in the particular year and domain associated with that cell. The OSP1098then determines whether this sum exceeds a threshold (TH1), represented by inequality2101. For each cell in the matrix ofFIG.20, the OSP1098may also calculate the total number of datasets (N) in the cell, which represents the total number of transactions of the client entity in the domain and calendar year associated with that cell. The OSP1098then determines whether the total number of datasets (N) in the cell exceeds a threshold (TH2), represented by inequality2102. According to the digital rule in the present example, if the sum of the transaction amounts for a particular cell exceeds a threshold TH1 and the total number of datasets in the cell exceeds threshold TH2 (i.e., if inequality2101and inequality2102exist for that particular cell), then the economic nexus for the domain and year associated with that particular cell is met and the OSP1098may as a result (e.g., depending on settings set by the client shown inFIGS.13-18) automatically start determining the tax obligations for transactions in the domain associated with that cell and start assessing sales tax immediately, and/or automatically initiate registration for the client with a tax authority for the domain, and/or send notifications, such as notification1079, regarding the economic nexus threshold being crossed.

FIG.22is a timeline chart2200illustrating a sample time evolution indicating whether or not transactions taxes are being automatically collected for a client and when de-registration for the client may occur in two different domains based on the same economic nexus threshold for each domain, but different nexus-ending rules for each domain, according to various embodiments of the disclosure, which is an improvement in automated computerized systems.

Shown inFIG.22is a sample time evolution relating to two different domains (Domain A and Domain B) with different nexus-ending rules. In particular, the nexus-ending rules indicate at what point the seller may stop collecting and remitting transaction taxes based on economic nexus thresholds no longer being met or exceeded over a particular time period. In various embodiments, such rules may be represented by or converted to digital rules, such as digital tax rules1070ofFIG.10.

The time axis Y02 is common to all the time evolution charts (chart Y01, chart Y05 and chart Y08) and measures years, but other periods could be used, such as quarters. The vertical axis Y03 shows a measurable quantity of transactions that is first to cross the threshold (number of transactions or total monetary amount indicated by the label “quantity” on the vertical axis Y03 of chart Y01). The threshold is indicated by the horizontal line labeled “Nexus Thr” on chart Y01. The vertical axis Y06 of chart Y05 and vertical axis Y09 of chart Y08 indicate a binary value of true or false indicating true if the seller is to collect and remit sales tax for the respective domain (or is to be registered to do so with the respective domain) based on whether and when the threshold shown in chart Y01 has been crossed in either direction by the quantity of transactions of the seller shown in chart Y01.

In the present example, as shown on chart Y01, the quantity of transactions for the seller crossed the economic threshold half way between year Y1 and year Y2. As a result, the value of the vertical axis Y06 of chart Y05 switches from false to true half way between year Y1 and year Y2 on horizontal axis Y02. Similarly, the value indicated on the vertical axis Y09 of chart Y05 also switches from false to true half way between year Y1 and year Y2. At the end of year Y3, however, as shown on chart Y01, the threshold is no longer met or exceeded. Therefore, according to the nexus-ending rules for Domain A, the value of the vertical axis Y06 of chart Y05 switches from true to false at the beginning of the next year (year Y4). However, according to the different nexus-ending rules for Domain A, the vertical axis Y09 of chart Y08 remains true and does not switch from true to false until the beginning of the following year (year Y5). Thus, in some embodiments, the OSP1098over time may automatically start or stop the tax obligation calculation, tax collection, and tax registration or deregistration activities for Domain A based on the true or false value of the vertical Y06 axis of chart Y05. Also, the OSP1098over time may automatically start or stop the tax obligation calculation, tax collection, and tax registration or deregistration activities for Domain B based on the true or false value of the vertical Y09 axis of chart Y08.

FIG.23is a timeline chart illustrating a sample time evolution indicating whether or not transactions taxes are being automatically collected for a client and when de-registration for the client may occur in two different domains based on the same economic nexus threshold for each domain, but different nexus-ending rules for each domain and de-registration for the client based on a configurable cool-off period or through predictive analytics for when the economic nexus threshold is no longer crossed, according to various embodiments of the disclosure, which is an improvement in automated computerized systems. In the example shown inFIG.23, the sales number in Y4 would warrant not to renew or keep the registration for collection of sales tax in Y5. By configuring an extended cool-off period, the automated flow described inFIG.23is further optimized to avoid an unnecessary and undesired series of registration and de-registration events.

In an example embodiment, the data collected from the seller over many years combined with other data from external or internal systems of the OSP1098may train an analytics prediction model that suggests to retain the registration for longer periods even when the current data flow suggests to trigger the re-registration procedure. This avoids unwanted cost for registration and deregistration activities and the associated legal obligations.

The two outlined optimizations enable avoiding unnecessary registration and de-registration events and are independent from the event that the nexus status has changed and, therefore, the collection of taxes shall be commenced/suspended. In particular, for Domain A, the OSP1098has a cool-off period2302after the threshold is no longer met or exceeded before stopping the automatic collection of sales tax for the seller or deregistering the seller. In some embodiments, the cool-off period2302may be a standard amount of time after the nexus threshold is no longer met or exceeded. However, for Domain B, the OSP1098has a prediction period2304after the threshold is no longer met or exceeded which may use the sales amount indicated on vertical axis Y09 in which the OSP1098will predict whether and for how long the sales amount indicated on vertical axis Y03 will continue to be below the threshold. The OSP1098may keep the value indicated on the vertical axis Y09 as true for an extended period of time based on a prediction that the sales amount indicated on vertical axis Y03 will again cross the threshold in the current year (e.g., Y4), which it did as indicated on chart Y01, after which a standard cool off period2306may be entered.

The embodiments described above may also use synchronous or asynchronous client-server computing techniques, including software as a service (SaaS) techniques. However, the various components may be implemented using more monolithic programming techniques as well, for example, as an executable running on a single CPU computer system, or alternatively decomposed using a variety of structuring techniques known in the art, including but not limited to, multiprogramming, multithreading, client-server, or peer-to-peer, running on one or more computer systems each having one or more CPUs. Some embodiments may execute concurrently and asynchronously, and further communicate using message passing techniques. Equivalent synchronous embodiments are also supported. Also, other functions could be implemented and/or performed by each component/module, and in different orders, and by different components/modules, yet still achieve the functions of the systems and methods described herein.

In addition, programming interfaces to the data stored as part of the system controller210and other system components described herein may be available by mechanisms such as through C, C++, C#, and Java APIs; libraries for accessing files, databases, or other data repositories; through scripting languages such as JavaScript and VBScript; or through Web servers, FTP servers, or other types of servers providing access to stored data. The databases described herein and other system components may be implemented by using one or more database systems, file systems, or any other technique for storing such information, or any combination of the above, including implementations using distributed computing techniques.

Different configurations and locations of programs and data are contemplated for use with techniques described herein. A variety of distributed computing techniques are appropriate for implementing the components of the embodiments in a distributed manner including but not limited to TCP/IP sockets, RPC, RMI, HTTP, Web Services (XML-RPC, JAX-RPC, SOAP, and the like). Other variations are possible. Also, other functionality may be provided by each component/module, or existing functionality could be distributed amongst the components/modules in different ways, yet still achieve the functions described herein.

Where a phrase similar to “at least one of A, B, or C,” “at least one of A, B, and C,” “one or more A, B, or C,” or “one or more of A, B, and C” is used, it is intended that the phrase be interpreted to mean that A alone may be present in an embodiment, B alone may be present in an embodiment, C alone may be present in an embodiment, or that any combination of the elements A, B and C may be present in a single embodiment; for example, A and B, A and C, B and C, or A and B and C.

As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present disclosure as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

The various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the embodiments in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled. Accordingly, the claims are not limited by the disclosure.