WO2021168502A1

WO2021168502A1 - Natural business process language system and method

Info

Publication number: WO2021168502A1
Application number: PCT/AU2021/000021
Authority: WO
Inventors: Eric Cameron WILSON
Original assignee: Docblaster Pty Ltd
Priority date: 2020-02-28
Filing date: 2021-03-01
Publication date: 2021-09-02
Also published as: GB202214042D0; AU2021227711A1; GB2608740A

Abstract

Data obtained from forms presented to end users, along with inventories, are together used by a computer system executing program logic. This produces reports by analyzing spatial form layout information and information types, and concatenating segmented product code tags according to end user interactions, to reduce custom programming of computer applications.

Description

Natural Business Process Language System and Method

This is best method known to the inventor.

The invention relates to the field of business process automation using software and computers.

INTRODUCTION

Until now, perhaps the best way to quickly create human-usable computer programs comprising user forms, inventory and reports has been known as “agile software development”. This involves computer programmers working in close collaboration with users, and employing iteritive development techniques instead of working from formal system specifications. Hand coding with rapid application development tools and pre-built systems or object frameworks is the usual practice. Graphical representations of software and data structures may assist this process, some even allwoing dragging and dropping objects one to another, and automatic code generation.

But the problem with all such approaches is that a programmer needs to be made to understand the “business problem” - relating to an organisation’s activities and the information required to perform them - to create even a simple solution. The cost of such programmers is beyond the reach of many small businesses and uneconomic in many other situations. Furthermore, requirements can change before a suitable software developer can be engaged and given enough time to change the system accordingly.

On the other hand, the natural language of human-usable business processes is well known by managers - such as online or written form(s) a person can fill in, inventory data against which the person’s choices are compared and/or calculated, and reports showing the results.

For example, a cost estimate process for a product or service may ask an end-user a series of questions with the answers entered as form data. Such answers will evaluated by a computer program designed to ascertain those items required to perform the service or create the product, so that a list of items containing prices can be produced in a report showing how much the product and/or service will cost.

In another scenario, a student may enter answers into a quiz which is compared with a list of possible responses each of which has a grade. When the quiz is over the student may receive a report as to what answers were incorrect and a total grade for the correct answers. Likewise a sports scorer might provide input into a computer system as to the games’ events, while a rules engine calculates the effect those events have on the score of the game, and reports that score to a score board. A simpler scenario involving the same natural business language tripartate of forms, inventory and reports is where a form letter contains address and name fields which is merged in a word processor with a contact database to create a more personalised letter.

While the simple matching of column names to placeholders in the mail merge scenario above can be created by end users without any help from programmers, more complex scenarios require programming even if only using a query-builder with the logical operators And, Or, Not. However, creating such queries is beyond many end users because instructions must sometimes be bracketed into separate steps to access the relevant information. This involves a level of abstract reasoning and/or comprehension of the underlying data structure most people aren’t used to and don’t have the time or the inclination to learn. What is needed is a simple way to use the natural language of business for business process automation employing software and computers, but without the need for computer programmers. Indeed such is required to democratise computing for customised small business process automation economically, and also suitable for cloud computing.

DESCRIPTION

It is an object of the invention to reduce the need for computer programmers when automating business processes (or parts thereof) with computerisation. Further or alternatively, it is an object of the invention to make automating business processes with computerisation more affordable or faster or both. Also further or alternatively, it is an object of the invention to provide a simpler means of computerised business process automation created by non programmers using natural business language.

In this specification, natural business language is data obtained from forms presented to end users, along with inventories, which together are used by a computer program to produce reports, by way of an organisation’s product codes. These codes are also known as stock keeping units (SKUs). It is common for SKUs to do more than uniquely identify items which an organisation may handle. They also may contain information about a particular item embedded within them. For example, a product code “TeeShirtNoSleeveBlueL” could refer to a blue tee shirt which has no sleeves, is blue in colour, and large in size.

The invention now disclosed uses computer(s) differently by using spatial form layout information and/or information types, coupled with segmented product code information, to discern an intended program logic according to end user interactions.

To this end the intrinsic spatial logic of end user data acquisition can be subtle: For example, a series of selections on a form end users are asked to complete or approve, may well directly relate to the segments in an SKU or else to multiple SKUs plus one or more SKU segments; and a text input field containing a number that is presented proximate to an end-user selection may well represent the number of units of that selection. So in a simple tee shirt example, such directly- related questions to SKU fragments might be “Sleeves or no sleeves?”, “Red, blue or green?”, “Small, medium or large?”. But if the tee shirt is bundled with other clothes or is offered with something else as a promotional item, other SKUs and/or fragments thereof may be involved in the end user’s selection.

The invention leverages such relationships by using SKU fragments placed in tags that are associated with the placeholders that allow forms to be filled. For example, underlines may represent a placeholder for alpha and/or numeric data entry, square brackets “[ ]” may represent check boxes while a series of bracket sets “( )” with adjacent descriptions may represent discrete options. Within an electronic document, such textural placeholders for data entry may be associated with a ‘tag’ by entering parts of product codes (SKU parts) into a comment area or hyperlink value related to that textural data placeholder; Or SKU fragments may more suitably be tagged as “Additional Information” or similar property found in the properties dialog box of a word procesor - e.g. LibreOffice Writer’s form controls for example. Alternatively, when in either printed or electronic form, part of an SKU may be specified between left “<” and right “>” elbows as “tagged” in close proximity to the data entry placeholder, or some other means of association may be used. The text may then be converted to an online form for users to fill in; or in another embodiment, printed on paper with optical character recognition employed to create a version of the form in memory which may or may not be displayed; or in another embodiment, ‘run’ locally within a host application such as a word processor.

The order of the placeholders as presented to the user or the order in which end user input is sought to be obtained, is used as the order in which tag values will be concatenated in an attempt to match the concatenations to SKUs in the inventory. Any such inventory matches may be added as line items to one or more reports. In the above non-limiting simple tee shirt example therefore, a list of three options may be given, each tagged with relevant SKU fragments. The “( ) Sleveed" and “(x) No sleeve” options may be associated with “ <TeeShirtSleeved> ” and “ <TeeShirtNoSleeve> ” tags receptively. The “(x) Blue ( ) Green ( ) Red” options may be tagged “ <Blue> <Green> <Red> ” respectively. The “( ) Small, ( ) Medium (x) Large” options may be tagged “<S><M><L>” respectively.

An “x” between the brackets in this example may denote a pre-filled or default option, in which case the default SKU obtained by concatenating the tags in the order in which their places were presented (that is the order information is sought to be obtained by the organisation in its natural language) would be the “TeeNoSleeveBlueL” simple example tee shirt SKU previously mentioned. When a series of concatenated tags matches an SKU (or visa verse), a line item may be added to the report to be read by an end user. Alternatively, the report may be in the form of a data to be used by another computer system.

The reported line item could contain an inventory item or part thereof, and in particular embodiments, also include a calculated value. Without limitation, such a calculated value may include the number entered into a text field multiplied by a price contained in a corresponding inventory item as has been determined to correspond by a concatenation of tag fragments. Another calculated value may be a tag or a series of tags which after the SKU contain a formula or script to be applied, such as adding to, subtracting from or discounting the cost of a a line item. In another non-limiting example, a tag may contain no SKU but only a formula or reference to a script, to use with a value from the previous line item; this may be used to calculate commissions or discounts for example as a separate line item based upon whatever an end user has chosen to facilitate the creation of the line item above it.

In this way, end user selections involving complex relationships may be automated by leveraging the natural language of a business process instead of resorting to custom programming. This is because the invention requires no abstract reasoning of the kind used in logical query building or traditional code writing. In the above simple example, the required information was obtained after three stages of end user consultation concerning a range of 18 possible types of tee shirt (from the 2 x 3 x 3 different shirts available). Little more than the existing SKUs already known to the hypothetical organisation plus the information asked of end users to determine the appropriate item, can achieve such a triple level of functionality. Of course this could be far deeper depending on the sophistication of a business’s SKU schema.

Thus it can be said the invention resides in at least one computer system (including at least one input means, output means, memory and CPU) executing instructions capable of:

Taking text as input;

Converting text containing placeholders for fields, check boxes, radio buttons, selectable lists or widgets into one or more online forms capable of being filled by an end user;

Wherein the text also has tags associated wth two or more placeholders for end user data; Wherein the said tags contain only a fragment of an SKU;

Wherein the order of the said placeholders presented to the end user or the order of the end user ’s data entry, is ascertained;

Wherein the tags are concatenated in the said order to an end user;

Wherein concatenated tags are checked against an inventory to see if they match any SKU Wherein any matching SKU or part thereof is added as a line item to a report for output;

It will be appreciated that a widget may consist of a date field such as “ _ / / of signing field such as ‘/ _ /” or other specialised end user input area.

In another form the invention resides in a method implemented in at least one computer system (including at least one input means, output means, memory and CPU) which:

Presents a form to an end user;

Takes form input data or approval of pre-filled or default data from the end user;

Associates the input data with SKU fragments;

Then:

Concatenates said fragments corresponding to end user choice(s) in the order the applicable form data was presented to or sought to be obtained from the end user;

Uses said concatenated fragments to match to SKUs to include inventory items or parts thereof in a report;

Provides the report to an end user or other system.

It is to be understood that embodiments of the invention may add up the cost of reported inventory items to acertain a total cost or otherwise perform calculations.

Also, tags need not be displayed to an end user who is filling the said online form for a particular embodiment of the invention to work. Tags which do not correspond to any SKU or fragment thereof may be used for other purposes, and end user inputs that are not tagged can be used to capture end user data in the usual way.

In some embodiments, the process of converting the text into an online form might instead be performed using optical character recognition to convert a paper form to pre-filled input text.

In a preferred embodiment a numeric value entered into a text field indicates the quantity of items a concatenation of tags refers to, if a tag is in close proximity to the numeric value.

In another preferred embodiment, a tag associated with a check box may contain a comma (or other character) to delimit a pair of values, one if the check box is selected (i.e. True) and the other if it is not (i.e. False). For example, if the sleved/no-sleeve option was represented by a “[x] Sleeves” check box, the tag value could be “<Sleeves, Nosleeves>” accordingly. In this example a tee shirt with sieves is the pre-filled or default option as denoted by the “x”.

In another preferred embodiment a quantity value may be part of a tag as a prefix of suffix to the SKU or SKU fragment. For example, the tag <3 x TeeShirtNoSleeved> contains a quanity value of 3 delimited by the characters “ x “ and an SKU fragment to start the concatenation. If this tag was associated with the list “Tee shirt - with sleeves / Tee shirt - no sleeves” then the default value in a proximate text field would be “3”.

It will be appreciated that where the invention resides in more than one computer system, these are connected via a computer network at least from time to time. It will also be appreciated that text may be found in a word processor document, whereby placeholders may be form controls and the tags may be a property of those form controls. It will be further appreciated that some situations may require a further step of reformatting, translation or modification of inventory items into a form suitable for input into the invention. It is also to be understood that ascertaining the order of form data presentation may require fuzzy logic to determine which lines of text different sized or positioned items belong to, and text fields proximate to end user selections.

Often there will not be a perfect correlation between SKU fragments and answers sought from end users via form data. For example, a check box confirming attendance of a school excursion to the zoo may include an SKUs relating to transport and an entry fee. In such an example a check box entry of “[ ] Yes, my child will attend <Trainfare+ZooEntry> ” may add two line items to the report sent to the parent. In such an embodiment the invention could use plus signs (or other character(s)) to delimit more than one item triggered by the one end user choice. However if a free tee shirt was included, the start of the tee shirt’s concatenated tags may also be added. In that case the example may read: “[ ] Yes, my child will attend and get a free Tee-shirt <Trainfare+ZooEntry+TeeShirt>”. If there is no SKU with a value of “TeeShirt” subsequent form options could be used to specify what kind of tee shirt in order to enliven the associated tags containing corresponding SKU fragments to be concatenated when the form data is processed. On the other hand, form data such as

“[ ] Yes, _ children will attend <Trainfare+ZooEntry> ” would be taken to show the number of children attending if an end user filled the underline placeholder with a numeric value.

The extent of concatenation required to make a match may vary. In one embodiment, the first match between a tag and a SKU may be used. In another embodiment, a certain number of concatenated fragments may be required to make a match. In yet another embodiment, a dash or other character(s) at the end or beginning of a fragment may indicate it should not be matched without being concatenated with other fragment(s).

In a preferred embodiment the report is merged with a report template to provide output to an end user. Such reports could be created from a template containing substitute tags for totals, taxes, discounts and the like, based upon values in line item/s created by the invention. Such substitute tags may also contain formulas or references to scripts to operate on a value represented by the substitute tags.

In another preferred embodiment, if a form is not specified or fully or properly specified, the invention may infer a form from the inventory, such as by assuming all inventory items may be included in a form to be chosen by an end user enering a quantity value in text field associated with each SKU.

FURTHER DESCRIPTION

The following further description of a simple illustration of the invention in operation is provided as an aid to understanding.

Figure 1 provides some example code fragments relevant to the creation of a form using text saved from a word processor. The proximate association of tags containing SKU fragments as dummy hypretext links relate to user inputs, which inputs when acted upon by an end user and combined in some way, will correspond with an SKU in the illustrative inventory of Figure 4. Figure 2 is a screenshot of what an embodiment of the invention presented to an end user may look like when supplied with the text of Figure 1. The tags are associated in program memory with the visible user radio button inputs.

Figure 3 is a representation of a report template which may be suitable to present an embodiment of the invention’s output.

Figure 4 is an example inventory in comma delimited format.

Figure 5 is a flow diagram describing the ordering of end user inputs. For communicating in natural English the ordering is according to screen locations reading from left to right, top to bottom; and the resolution of tag fragments such as specified in Figure 1 as selected in Figure 2 to the corresponding inventory entries of Figure 4.

Figure 6 is a flow diagram detailing the process of tag concatenation for line item matching to provide input to a report writer where calculations may be performed on line item data.

Figure 7 is an example of the output of Figure 6 as might be reported to an end user, the result of an embodiment of the invention. However much of the hypothetical organisation’s custom logic is contained within its inventory SKUs (Figure 4) in combination with the form text (Figure 1) as ascertained and processed by an embodiment of the invention.

Figure 8 is another example inventory in comma delimited format, this time specifying mandatory and calculated SKUs. The first inventory item with an SKU of “Inspctl” causes a particular embodiment of the invention to add a line item worth 80 (auto-quantity of 1) without user selection. Likewise, the second inventory item with an SKU of “Del” adds 25% of the previous item created by the invention. Likewise, the third inventory item with an SKU of “Pre20” subtracts 20% of the previous item’s value from the report’s total as a separate line item. Likewise, the fourth inventory item with an SKU of “ExtrPrsn” adds the previous price less 200. Likewise, the fifth inventory item with an SKU of “Hol3” adds one and a half times the previous price. Likewise, the sixth inventory item with an SKU of “OvrTm” ads l/365th of the previous price, which could be associated with a proximate input such as a text field to multiply this by the number of extra days required. In this way, a single numeric value preceded by one of *,x,/,\,+-,- or appended with % or both, can in a particular embodiment provide the additional flexibility of calculated tags based on SKUs in relation to the previous line item created by the invention.

Figure 9 shows a similar arrangement by which substitute tags of a Total value generated from line item values already created by the invention, can specify modifications to that Total value. In a particular embodiment, the first Total substitute tag in an example template is the total of the Lineltems created by the invention. The second such tag overrides the total value with a fixed price, the third tag discounts the Total by 10%, the fourth subtracts 300 off the total, meaning the final modified Total has a value of 240.

Figure 10 likewise shows an arrangement by which substitute may amend a calculated total value generated from line item values already created by the invention, with the amendment itemised. In a particular embodiment, an amendment tag allows the substi tution of a value of 10% of Total and adjusts Total accordingly. Another substitutes a value of -50% and adjusts Total accordingly, while yet another substitutes a value of 100 and adj usts Total accordingly. Figure 11 also shows an arrangement by which substitute may create a calculated as an aside to a total value generated from line item values already created by the invention, with the aside value itemised. In a particular embodiment, an aside tag allows the substitution to be included in an HTML template using a calculation based on Total value without changing the Total. By way of example, the aside values would if the Total was $1000, indicate 2 x $41.67 and 10 x $91.67 installments.

Because an intended business logic may be discerned by relying on the structure of SKUs and layout of end user inputs with optional formulas, and not hand coded business rules running in program code, such an embodiment of the invention may be well-suited to linear scaling on cloud computing infrastructure for mass take-up by smaller organisations. However in all cases where technical considerations permit, this specification should be read so that a particular embodiment of the invention may have some or all of the features or attributes of other embodiments described herein.

It will be appreciated that the invention may be suitable wherever the natural business language tripartite of form(s), inventory and report(s) is required to be usable by humans; and may be used to automate all or part of a business process or processes.

By using form layout and/or datatypes together with SKU segmentation and end user choice(s) to determine an intended program logic, the invention provides great advantages over the prior art. These include one or more of: orders of magnitude faster software development, created at much lower cost by non-programmers, and allowing organisations to update their business processes far more often as needed.

Claims

1. At least one computer system including at least one input means, output means, memory and CPU executing instructions capable of:

Taking text as input;

Converting text containing placeholders for fields, check boxes, radio buttons, selectable lists or widgets into one or more online forms capable of being filled by an end user; Wherein the text also has tags associated with two or more placeholders for end user data; Wherein the said tags contain only a fragment of an SKU;

Wherein the tags are concatenated in the acertained order according to end user input; Wherein concatenated tags are checked against an inventory to see if they match any SKU; Wherein any matching SKU or part thereof is added as a line item to a report for output.

2. The system of claim 2 wherein a numeric value entered into a text field or otherwise selected indicates the quantity of items a concatenation of tags refers to, if a tag is proximate to the numeric value on a form.

3. The system of claim 2 whereby the order of form data presentation is ascertained by fuzzy logic determining which text fields are proximate to end user selections.

4. A method implemented in at least one computer system (including at least one input means, output means, memory and CPU) which:

Presents a form to an end user;

Associates the input data with SKU fragments;

Then:

Provides the report to an end user or other system.

5. The method of claim 4 wherein a numeric value is entered into a text field or otherwise selected form a list, indicates the quantity of items a concatenation of tags refers to, if a tag is proximate to the numeric value on a form.

6. The method of claim 4 whereby the order of form data presentation is ascertained by fuzzy logic determining which text fields are proximate to end user selections.

7. A computerised process utilising spatial form layout information and information types with segmented product code information, to discern an intended program logic according to end user interactions; with said computerised process executing on at least one computer system including at least one input means, output means, memory and CPU.

8. The process of claim 7 in which a numeric value has been entered into a text field or otherwise selected form a list by an end user, to indicate the quantity of items a concatenation of tags refers to, if a tag was proximate to the numeric value on a form.

9. The process of claim 8 in which the order of form data presentation was ascertained by fuzzy logic determining which text fields are proximate to end user selection.