TECHNICAL FIELD

In a particular aspect, the present invention relates to a system and method which may assist a User (or system; collectively a User) to submit data relating to a Form (or template or GUI or dataset; collectively a Form); especially where some or all of that data does not match the specifications of that Form. The data gathered may now proceed beyond Form- submission stage and be reviewed for processing.

The nature of identifying these portion(s) of a Form (often with accompanying data which may indicate a suggested, preferred or permanent solution) may also subsequently be used as a basis for improvement to the Form or related processes.

Implementations may relate generally to a user or system input [collectively hereafter: a User] to electronic questionnaires, form documents, web forms, GUIs, software interfaces or database interfaces [collectively hereafter: Forms]. A Data item entered by a User may be data in a field, checkbox, slider, dropdown, selectable list, lookup, 'radio' button, Form button, link, or other method of input to a Form.

Specifically (but not exclusively) the intention of the User or the Form may not be satisfactorily fulfilled without the invention; where a User Data entered or submitted to a Form may be unexpected or unanticipated by the design or use of a Form or an associated process.

BACKGROUND

Any discussion of documents, devices, acts or knowledge in this specification is included to explain the context of the invention. It should not be taken as an admission that any of the material forms a part of the prior art base or the common general knowledge in the relevant art in Australia or elsewhere on or before the priority date of the disclosure and broad consistory statements herein.

Forms are used to obtain Data from one or more User, and the data collected is often passed to a database, application or other repository. Increasingly input is from a human user in conjunction with selected inputs from a database, application, memory or other repository (e.g. mapping data from another database; or perhaps an AI; or perhaps an RPA; or perhaps a combination).

Existing tools enable storage of Form Data into a database or other repository.

Existing tools and processes enable processing of Form Data; in many instances. However, in many other instances the Form design may not match the User requirements or the Data being presented by the User. In many instances this can have an adverse impact on the processing efficiency or processing efficacy of the Form Data or the purpose of the Form.

Some general examples:

1. a Form may lack a field the user would need

2. a field may have a validation rule set which does not allow the user to enter the necessary data

3. a field may use a drop-down or other lookup set of data which lacks the required value(s) the user needs to input

4. A Form may require data which the user is unable to provide

In many cases the Form may not be able to be submitted by the User.

In many cases Forms are submitted where the data is incorrect, unsuitable or incomplete.

Thus, it may be advantageous to provide a new form, or new method of processing or submitting form data, which limits, ameliorates or overcomes problems or drawbacks associated with prior art forms, or provides users with an effective alternative.

SUMMARY OF THE INVENTION

According to one aspect, the invention may provide a method allowing entry (or non- entry) of Data into User Interface (UI) Form fields which does not match the design expectation of those fields; subsequently altering the behaviour of processing actions on the UI Form and form Data. In some cases the UI Form may be altered to allow this behaviour, in other cases there may be a separate process triggered - or some combination of the two. In some cases the User may be allowed to provide entry of data regarding other Form elements (for example: the User may provide input regarding why an Instruction paragraph is not suited to their purpose).

According to another aspect, recording of 'User Exception Data' (UED, as it is called herein) may provide a mechanism for possible review and alteration of the Form design and actions upon it. This may allow improvement to the Forms themselves, and may

subsequently allow improved processing efficiency and efficacy.

According to another aspect, UED may be used as a design tool. For example, the UED process may be used to 'break' submission or processing of a UI Form; and yet allow recording of User input regarding that Form - even to the point of a User proposing a new UI Form.

According to another aspect, the invention may provide a method of processing form data comprising: initiating a user exception data (UED) process in respect of a UI form, the UI form having data input fields, at least one of the data input fields being governed by predetermined validation rules for inputted data, which rules when broken prevent submission of inputted UI form data, the UED process being used to avoid breaking a validation rule or negate a broken validation rule; and, submitting inputted UI form data for storage or review.

Initiating the UED process may comprise generating a UED form.

Initiating the UED process may comprise presenting a UED form.

The user or users may be able to access the server to process form data by submitting inputted UED form data for storage or review. In this specification, the term 'User' refers to anything capable of inputting data into a form, be it biological, electronic, or otherwise. Thus, a User may be, for example, one or more humans, AI, a combination of human and AI, a computer program and/or a Robotic Process Automation (RPA) system.

The method may comprise reviewing inputted UED form data and modifying, for future use, the UI form template to accommodate for the inputted UED form data.

According to another aspect, the invention may provide a server for processing user interface (UI) form data, the server comprising: a processor and a memory including computer-executable instructions, one or more computing devices to be in selective communication with the server through a communications network; wherein a user or users of the one or more computing devices are able to access the server to process the UI form data by: initiating a user exception data (UED) process in respect of a UI form, the UI form having data input fields, at least one of the data input fields being governed by predetermined validation rules for inputted data, which rules when broken prevent submission of inputted UI form data, the UED process being used to avoid breaking a validation rule or negate a broken validation rule; and, submitting inputted UI form data for storage or review. The server may comprise a single computing device, or multiple (two or more) computing devices.

According to another aspect, the invention may provide a non-transitory computer- readable medium comprising computer-executable instructions that, when executed on a processor, directs a processor to at least: initiate a user exception data (UED) process in respect of a UI form, the UI form having data input fields, at least one of the data input fields being governed by predetermined validation rules for inputted data, which rules when broken prevent submission of inputted UI form data, the UED process being used to avoid breaking a validation rule or negate a broken validation rule; and, submit inputted UI form data for storage or review.

In another aspect, the invention may provide a method of processing form data comprising: presenting a user interface (UI) form, the UI form having data input fields, at least one of the data input fields being governed by predetermined validation rules for inputted data, which rules when broken prevent submission of inputted UI form data;

presenting a user exception data (UED) form, the UED form being used to avoid breaking a validation rule or negate a broken validation rule; submitting inputted UI and UED form data; reviewing submitted UI and UED form data; and, modifying, for future use, the UI form template to account for the submitted UED form data. The method may further comprise presenting the modified UI form and repeating the process of presenting the UED form, submitting and reviewing inputted data, and modifying the UI form template accordingly. Or said another way, the method may further comprise repeating the process of presenting the UI form as modified and UED form, submitting and reviewing inputted data, and modifying the UI form template accordingly.

In another aspect, the invention may provide a method of processing form data comprising: generating a user interface (UI) form, the UI form having data input fields, at least one of the data input fields being governed by predetermined validation rules for inputted data, which rules when broken prevent submission of inputted UI form data;

generating a user exception data (UED) form, the UED form being used to avoid breaking a validation rule or negate a broken validation rule; submitting inputted UI and UED form data; reviewing submitted UI and UED form data; and, modifying, for future use, the UI form template to account for the submitted UED form data. The method may further comprise generating the modified UI form and repeating the process of generating the UED form, submitting and reviewing inputted data, and modifying the UI form template accordingly. Or said another way, the method may further comprise repeating the process of generating the UI form as modified and UED form, submitting and reviewing inputted data, and modifying the UI form template accordingly.

In another aspect, the invention may provide a method of processing form data including the steps of: generating a user interface (UI) form, the UI form having data input fields; generating a record form in respect of the UI form, the record form being used to record information relating to the UI form; submitting the record form; reviewing submitted record form data; and modifying the UI form template to account for the submitted record form data. The method my further include repeating the steps of generating the UI form as modified and record form, submitting and reviewing inputted data, and modifying the UI form template accordingly. The record form may be generated at the call, prompting, or request of the user.

In another aspect, the invention may provide a method of processing form data including the steps of: generating a user interface (UI) form, the UI form having data input fields; generating a record form in respect of the UI form, the record form being used to record information relating to the UI form, record form, or form data entry; submitting the record and/or UI form; reviewing submitted record and/or UI form data; and modifying the UI and/or record form template to account for the submitted record and/or UI form data. The method my further include repeating the steps of generating the UI and/or record forms as modified, submitting and reviewing inputted data, and modifying the UI and/or record form template accordingly. The record form may be generated at the call, prompting, or request of the user.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the invention may be more clearly understood and put into practical effect there shall now be described in detail preferred embodiments in accordance with the invention. The ensuing description is given by way of non-limitative examples only and is with reference to the accompanying drawing, wherein:

Fig. 1A is a diagram of an exemplary User Interface for calling a User Exception Data process;

Fig. IB is a diagram of an exemplary User Exception Data interface;

Fig. 2 is a diagram of an exemplary network;

Fig. 3 is a diagram of exemplary client/server architecture;

Fig. 4 is a diagram of a portion of an exemplary computer-readable medium;

Fig. 5 is a diagram of an exemplary User Interface form;

Fig 6 is a diagram of an exemplary User Exception Data form;

Fig. 7 is a flow diagram illustrating prior art form processing involving validation on form submission;

Fig. 8 is a flow diagram illustrating prior art form processing involving inline validation during form completion;

Fig. 9 is an exemplary flow diagram illustrating a method of processing form data; Fig. 10 is an exemplary flow diagram illustrating use and interaction of a User Interface form with inline validation and a User Exception Data form; and

Fig. 11 is an exemplary flow diagram illustrating a User Exception Data resolver process.

MODES FOR CARRYING OUT THE INVENTION

FIG. 1A is an exemplary diagram of a Graphical User Interface (UI) Form that illustrates a presentation of a Form to a User, and shows an Operator (530) which may be used to call the User Exception Data (UED) process (FIG. IB), shown as a separate graphical user interface. The UI Form and UED Form may, for example, be presented as part of a web browser window, software interface, database interface, or presented in various other mediums.

The UED process may gather information, may provide a tracking mechanism, and may provide information useful to regulate and improve the UI Form's efficacy and efficiency in future. The UED process may be used to pause or interrupt the normal UI Form processing - even to the point of being used in its stead.

In another instance, the introduction of a UED process may allow non-standard data within the UI Form - and not call a separate interface. In another instance, the UI Form may be modified to encompass the UED process. In another instance, the UI Form may not allow any interaction of modification - but we may use a process to gather relevant UI Form information and allow user interaction in a separate system.

FIG. 2 is an exemplary diagram of a network 200 in which systems and methods consistent with aspects of the invention may be implemented. Network 200 may include multiple clients 270 connected to multiple servers 220,230,240 via a network 210. Three clients 270 and three servers 220,230,240 have been illustrated as connected to network 250 for simplicity. In practice, there may be more or fewer clients and servers. Also, in some instances, a client may perform a function of a server and a server may perform a function of a client.

Clients 270 may include client entities. An entity may be defined as a device, such as a personal computer, a wireless telephone, a personal digital assistant, a tablet, a smartphone, a laptop, smart TV, virtual PC, thin client, or another type of computation or communication device, a thread or process running on one of these devices, and/or an object executable by one of these devices. In other aspects, servers 220,230,240 may include server entities that gather, process, search, and/or maintain documents. In one implementation, server 220 may include a User Exception Data (UED) engine, database or software 224 usable by clients 270 or servers 220,230,240 or databases or other software engines connectable via the network 210 or within any segment of the Network 200. As will be described in additional detail below, UED engine 224 may receive user mappings of UI Form elements to UED Forms and/or the UED process.

While servers 220,230,240 are shown as separate entities, it may be possible for one or more of servers 220,230,240 to perform one or more of the functions of another one or more of servers 220,230,240. For example, it may be possible that two or more of servers 220,230,240 are implemented as a single server. It may also be possible for a single one of servers 220,230,240 to be implemented as two or more separate (and possibly distributed) devices.

While the UED ENGINE 224 and UI ENGINE 222 are shown together on one Server 220, it may be possible for them to be on separate servers, implemented across several servers, on distributed servers, housed entirely or partly on a Client, or otherwise housed. The preferred embodiment may be a redesign of 224 to integrate behaviours and aspects of 222.

Network 210 may include a local area network (LAN), a wide area network (WAN), a telephone network, an intranet, the Internet, or a combination of networks. Clients 270 and servers 220,230,240 may connect to network 210 via wired, wireless, and/or optical connections - or to one another directly.

FIG. 3 is an exemplary diagram of a client or server entity (hereinafter called

"client/server entity"), which may correspond to one or more of clients 270 and/or servers 220,230,240. The client/server entity may include a bus 310, a processor 320, a main memory 330, a read only memory (ROM) 340, a storage device 350, an input device 360, an output device 370, and a communication interface 380. Bus 310 may include a path that permits communication among the elements of the client/server entity.

Processor 320 may include a processor, microprocessor, or processing logic that may interpret and execute instructions. Main memory 330 may include a random access memory (RAM) or another type of dynamic storage device that may store information and instructions for execution by processor 320. ROM 340 may include a ROM device or another type of static storage device that may store static information and instructions for use by processor 320. Storage device 350 may include a magnetic and/or optical recording medium and its corresponding drive. Additionally, storage device 350 may include forms information storage area 355 for receiving and maintaining user data for form submission in accordance with UED or UI activity.

Input device 360 may include a mechanism that permits an operator to input information to the client/server entity, such as a keyboard, a mouse, a pen, voice recognition and/or biometric mechanisms, etc. In certain cases an AI may use this functionality also. Output device 370 may include a mechanism that outputs information to the operator, including a display, a printer, a speaker, etc. Communication interface 380 may include any transceiver-like mechanism that enables the client/server entity to communicate with other devices and/or systems. For example, communication interface 380 may include mechanisms for communicating with another device or system via a network, such as network 250.

As will be described in detail, the client/server entity may perform certain data processing-related operations. The client/server entity may perform these operations in response to processor 320 executing software instructions contained in a computer-readable medium, such as memory 330. A computer-readable medium may be defined as a physical or logical memory device and/or carrier wave.

The software instructions may be read into memory 330 from another computer- readable medium, such as data storage device 350, or from another device via communication interface 380. The software instructions contained in memory 330 may cause processor 320 to perform processes that will be described later. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement processes in various aspects of the invention. Thus, implementations of the invention are not limited to any specific combination of hardware circuitry and software.

FIG. 4 is a diagram of a portion of an exemplary computer-readable medium 400 that may be used by a client 270. In one implementation, computer-readable medium 400 may correspond to memory 330 of a client 270. The portion of computer-readable medium 400 illustrated in FIG. 4 may include an operating system 410, browser software 420, and UED and/or UI software 430.

The operating system 410 may include operating system software, such as the Microsoft Windows®, Unix, or Linux operating systems. Browser software 420 may include software associated with a web browser, such as the Microsoft Internet Explorer, Google Chrome, Safari, or Mozilla Firefox browser.

UED and UI software 430 may include a plug-in, an applet, a dynamic link library (DLL), a bookmark, or a similar executable object or process. Client 270 may obtain the executable object or process from server 220 or from a third party, such as a third party server, disk, tape, network, CD-ROM, etc. Alternatively, the executable object or process may be pre-installed on client 270 or presented via a software interface with server 220.

Additionally, UED and UI software 430 may cause a user interface (UI) object, to be presented within a web browser window or within the user interface software display. The user interface object may operate in conjunction with the web browser. In another implementation, the user interface object may be an integrated part of the web browser. In this latter implementation, the web browser may perform the functions of the user interface object. In yet another implementation, the user interface object is a process separate from the web browser.

A monitoring aspect of UED and UI software 430 may be automatically activated upon initiation of the UI to the User. For example: data validation of the Form fields.

FIG. 5 is an exemplary diagram of a Graphical User Interface 500 that illustrates a presentation of a Form to a User. The UI may, for example, be presented as part of a web browser window, software interface, database interface, or presented in various other mediums.

The method and system articulated may also be used to introduce a human- verification element into an otherwise automated process - especially for design-testing or review. For example: if a process design allows data input from one system to another (without human review or intervention) it may be useful to create a Form as an interim design-validation step - and allow use of the invention.

It may contain various UI identifiers and informational or instructional text, images, or video; such as a 'Page Title' (502), 'Title' (505), 'Sub-headings' (507) or 'Field Names' (508) with or without various associated 'Descriptions' (503) which may be hidden (for example: visible on mouse-hover) or minimised or referenced elsewhere or displayed only on certain user actions, for example.

It may contain various Data Fields (510) with or without 'Field Names' (508) and with or without various associated Descriptions (503); which may be filled by the User in various ways (including those described below), with various information. For example, the User may simply type the requested Data into a Field. Often Forms (and Fields) have validation rules.

It may contain various 'Operators' (520) associated with any part of the UI, which may assist the User with filling out the Form. These may include (but are not limited to) search boxes, sliders, drop-down menus, information buttons, hidden Fields (522), inline auto-search (e.g. when the User enters "John D" in the Name Field, there may be an auto- search for Names in a records list or system such as a database which supplies a clickable auto-complete to the User), inline lookups (similar to inline auto-search, but may be data contained within the Form itself; not a search of an external records system), radio-buttons, checkboxes, search buttons, data-validation notifications, data-validation graphics, flyouts, pop-up windows, etc.

In a similar vein, it may contain Operators which auto-complete one or more fields, for example: after certain fields have been completed (512). Those auto-completed fields may be unavailable for the User to complete or modify (515) (which is often referred-to as 'greyed-out').

Additionally, it may contain data which is auto-filled from another data source when the Form is presented. Those Fields may be 'greyed-out' or may be editable, depending on the UI Form design.

It may also contain a 'Submit' button or similar Operator to complete submission of the Form. This may commonly be used to trigger a data validation rule checking of the Form. It may also be designed to automatically proceed with submission of the form; which may also trigger a data validation rule checking of the Form.

Validation rules may be alterable by a process, application, software or system. As a non-exclusive example: an AI may be used to alter validation rules or define their behaviour.

The innovation as regards UI Forms lies in the introduction of the UED (User Exception Data) process by some means: the below provides examples of implementations to achieve that end.

In the case where a UI Form or Field may not be submitted for any reason (due to, for example, Fields not passing data validation rules) the UED process may be used to submit the Form Data for processing and/or review.

In the case where a UI Form or Field submission may be impeded for any reason (due to, for example, the User wishing to propose a design alteration) the UED process may be used to submit the Form Data for processing and/or review.

A suitable method would be to build UED calls into the Form itself, and also into the software or database which subsequently processes the Form data - but there will be implementations where that is not feasible in the beginning. A suitable method would also allow for as much recording of Form information and Form data into the UED process as possible (for example: Field name, validation rule(s) if any, data entered into a Field by the User, etc.).

Multiple implementation examples listed below may be implemented in a UI Form. According to one implementation of the invention, the UI Form may be modified to include several features. One such feature may be the modification of Field background behaviours: such as no-colour where Data has yet to be entered, blue where Data has been entered and has passed data validation, yellow where Data has been pre-entered by another system or process (for example, perhaps Cloning of a previous Form's Data into the current Form) and may be reviewed by the User, and Red where the data validation has not passed. In this example: where a Form is complete and has all blue Fields, the Form may be expected to be submitted by the User for normal processing; where Fields are yellow, they may turn Blue or Red as the User reviews them (for example, the User may be encouraged to 'tab' through all yellow fields to verify the data is correct in each); red fields may denote that the UED process will be called for those field(s); and no-colour may be used where data is simply pending entry by the User. These types of modification features may be applied in a variety of ways (e.g. background, border, text colour, etc.) or nearby elements (e.g. a changeable icon next to the Field); and not specifying them here should not set them outside the scope of invention. As noted above: this may be just one of the UED calls implemented in a Form; meaning some or all of the others below may also be implemented into the same Form.

According to another implementation, there may be additional Operators (530) installed in a Form to call the UED process. Those may be applied to some or all Fields (510); or may be applied to Form items (such as a Field Name (508) or Title (502); as nonexclusive examples). In such an implementation UED Operators may be shown as a selectable icon (530), for example.

According to another implementation, there may be Operators inserted into Fields; which not only display similar behaviour to the blue/yellow/red/empty Field background colours above, but also serve as an Operator which may automatically call the UED process if they are Red or call the UED process if they are actioned by the User.

According to another implementation, there may be a single UED Operator applied to the Form as a whole. In addition, if this approach were used, the single UED Operator may allow some or all Form Items (including Fields) to become selectable links, which may allow the User to then specify the UED data for selected part or parts of the Form.

According to another implementation, there may be a single UED Operator applied to the Form as a whole. This may allow data to be entered by the User in a UED process.

In another implementation, the UED process may be called automatically when a Field contains non-validated Data; and this may trigger when the User tries to submit the Form or another validation trigger (for example, when the user selects the next Field, or via an AI, or after a certain amount of elapsed time, etc.). In some cases, a Field may be found to be empty, and thus non-validated, and thus a validation trigger may call the UED process.

According to another implementation, 'special' data may be used to call the UED process. For example, entering "QQ" in a Field may allow that Field to pass validation rules, and may also be used to call the UED process at that time or at a later time (for example, after the Form is submitted the processing software could read the QQ as a 'break' code and send the Form data to be processed under a UED process; rather than proceed automatically). This may be useful in Forms which cannot be altered; and, for example, where the underlying data for data validation can be edited. This may allow the Form to be submitted after 'passing' validation rules (and, for example, the User may be able to enter applicable notes in a generic notes field - to supply the UED process with as much necessary data to complete the User's desired outcome correctly).

According to another implementation, all Data may have passed the validation rules of the Form - and yet the User may wish to call the UED process. For example, if the User wishes to alter the Form to account for an upcoming Form design need, they may choose to call the UED process and log their perceived need or requirement. In this example, the Form itself may not need to be submitted - the User is simply using the UED process to lodge a design requirement.

FIG. 6 is an exemplary diagram of a User Exception Data User Interface 600 that illustrates a presentation of a UED Form to a User. The UED may, for example, be presented as part of a web browser window, a new web browser window, software interface, database interface, xml file, or presented in various other mediums or other file types.

It may contain various identifiers and informational or instructional text, images, or video; such as a 'Page Title' (602), 'Title' or 'Sub-heading' (607) or 'Field Names' (608) with or without various associated 'Descriptions' (603) which may be hidden (visible on mouse-hover) or minimised or referenced elsewhere or displayed only on certain user actions, for example.

It may contain various Data Fields (610) with or without 'Field Names' (608) and with or without various associated Descriptions (603); which may be filled by the UED software (or an additional service; such as an AI), with various information.

Those Data Fields may be editable by the User, depending on the UED Form design

(609). It may contain a data record of a UI Form (500) and may provide accessible storage of that (612).

It may contain a User data area (620) - even though previous Fields may have been editable by the User.

It may also be designed to allow a further UED process to be called (for example: if the User wishes to provide design feedback on a UED, they may be allowed to call-up a new UED for that purpose).

There may be various 'Descriptions' provided which may assist the User (625).

There may be various Fields available to the User, where the User may choose to enter Data (most likely Data which would assist the UED process (630)).

There may be various Operators' (see 520, for example) associated with any part of the UED UI, which may assist the User with filling out the UED Form. These may include (but are not limited to) search boxes, sliders, drop-down menus, information buttons, hidden Fields (522), inline auto-search (e.g. when the User enters "John D" in the Name Field, there may be an auto- search for Names in a records list or system such as a database which supplies a clickable auto-complete to the User), inline lookups (similar to inline auto-search, but may be data contained within the Form itself; not a search of an external records system), radio-buttons, checkboxes, search buttons, data-validation notifications, data-validation graphics, fly-outs, etc.

In a similar vein, it may contain Operators which auto-complete one or more fields, after certain fields have been completed.

Additionally, it may contain data which is auto-filled from another data source when the UED Form is presented.

Multiple implementation examples listed below may be implemented to allow processing of UI Form data.

In one implementation, the UED process call may trigger collection of data from the UI Form and some or all associated properties, attributes, and other data - from the UI Form or associated systems (for example: a database for which the UI Form is presented). And may 'map' that data or transfer that information in another manner into the UED Form (and may establish a data record elsewhere). For example: if the UED process was 'called' regarding an email field in the UI Form, to allow the User to input data which the field failed to validate; then a UED Form may be created; and the UED Form may be populated with data regarding that UI Form name, Field's name, database identifier, attributes, current data contents, etc.; and the User may enter additional data in the UED Form. In this example, the original user UI Form may still be the primary vehicle to achieve the User's desired outcome - but instead of processing the UI Form automatically it may be processed in a more manual fashion using the additional UED data gathered using the UI Form. Thus the UED Form(s) created allow the User to use the UI Form; but modified to be fit-for-purpose, as required. And the UED Forms may also be used to subsequently review and refine the UI Form itself and the surrounding processes (perhaps enabling targeted improvements and a higher level of automation in the future).

In another implementation, a failure of data validation in a UI Form may call the UED process - but without a UED form. In this case, the UED process may allow the Form data to be processed - not via the expected UI Form process; but via a UED process. This implementation may record instances where the UED process was employed - and those may subsequently be used to review and refine the UI Form itself and the surrounding processes.

In another implementation, the UI Form might be modified by the UED process. For example, a data validation rule may be 'waived' and the UI Form submitted. Again, this implementation may record instances where the UED process was employed - and those may subsequently be used to review and refine the UI Form itself and the surrounding processes.

In some implementations, the UI Form may be able to be modified. In those cases a UED process may be called.

In another implementation, the UED process call may gather data by other means. For example, but not limited to: via manual entry, screenshot of the UI Form or Field, text- scrape of the UI, Al-assisted processing, OCR, or other method. Some of this data may be used for the UED process.

FIG. 7 is a simple diagram outlining a possible processing flow of a prior art Form, with validation checked upon submission - as it might stand before or without the invention. In this case, form submission is successful only if all inputted data accords with pre-specified validation rules, otherwise submission is rejected or prevented until such time as the inputted data has been modified to meet validation requirements.

FIG. 8 is a simple diagram outlining a possible processing flow of a prior art Form, with inline validation - as it might stand before or without the invention. In this case, data can only be inputted into a following field once data inputted into a present field accords with pre-specified validation rules, and form submission can only occur once the last field has been reached and data entered therein accords with validation rules.

FIG. 9 is a flow diagram illustrating an exemplary method for processing form data 945. The method comprises presenting a User Interface (UI) form 902 on a screen of a computing or communications device to a User. The UI form has data input fields, some of which are governed by predetermined validation rules for inputted data. Where these validation rules are broken, submission of UI form data may be prevented.

Following presentation of the UI form, the User (or, for example, Robotic Process Automation (RPA) system or other data input method) inputs data into the relevant data fields of the UI form 904.

Where data inputted does not violate any validation rules, the UI Form may be submitted without any further action. Note: in some instances the User may elect to call a UED as per 908 below (for example: where the User wishes to highlight a possible design alteration, they may use the UED process to highlight the proposed change - even though the data entered may match all the validation rules in the form). Note: in some instances the system may be designed to record all Form submissions where the inputted data is validated; and use this as part of AI integration - especially in relation to other Form submissions which may use the UED process.

An error notification may be generated and/or displayed where data inputted violates a validation rule of that field, and record (906) may be generated in the instance where the data is corrected by the User (possibly a person or AI) 905 - and this data may be

subsequently used for review by an AI or other review process.

An error notification may be generated and/or displayed where data inputted violates a validation rule of that field 942. (Error notifications may, for example, comprise the changing of a data field border line from black to red, or displaying a warning message, etc.)

A user exception data (UED) process may be triggered 907 by one of various possible means. For instance, the UI form may display an operator adjacent to or within a UI data field, which operator may be selected or activated 908 by a user in order to trigger the UED process. An operator may be activated by the user when inputted data, or data to be inputted, violates a validation rule governing the field in question. In another aspect, the UED process may be triggered by the user entering a pre-determined data code 910 into a UI data field where there is a potential rule violation. In yet another aspect, the UED process may be triggered automatically where data entered into a UI field violates a validation rule 912. It is also envisaged that the UED process could be triggered prior to any data being entered into the UI form.

In the illustrated version shown in Figure 9, one outcome of triggering the UED process involves altering the UI form to avoid breaking a validation rule or negate a broken validation rule 950, thereby enabling UI form data submission. In the particular embodiment shown, altering the UI form comprises waiving the actual or potential broken validation rule 952. The record of the UED triggered may be used for review and improvement processing.

Another or alternative outcome of triggering the UED process in the embodiment illustrated involves presenting (on the user's screen for example) a UED form 914. In one version, the UED form is a modified UI form 916. In another aspect, the UED form is a separate interface which broadly corresponds to the UI form or field(s) of the UI form which triggered the UED process 918. For instance, the UED form may contain fields which mimic those of the UI form 940, but avoid the rule violation. In another aspect, the UED form contains a field for describing the nature of the rule violation. In some embodiments, multiple UED forms are presented 944, simultaneously or apart in time, for a single or multiple potential or actual rule violations.

The user then inputs data into one or more of the UED form fields 920. The data may be, for instance, data which was to be inputted into a corresponding UI form field but for a rule violation, information describing the nature of the rule breach, and/or information describing how the UI form may be modified in future to account for the present data-rule mismatch. In one embodiment, some of these information items or all information may be provided by means of an AI, Robotic Process Automation (RPA), user-input or combined method.

In a particular embodiment, following input of data into the UI and UED form fields, the method includes determining whether use of the UED form and inputted UED form data is sufficient to overcome the actual or potential rule violation 948. Where usage of the UED form is determined to be sufficient, or in embodiments where no such determination is required, the inputted data is submitted for storage and/or review 922. In one embodiment, where there are multiple UED forms, the data may be collated for submission 944. In another particular embodiment, data from the UI and UED forms may be collated for submission 946. In one embodiment, the UI and UED form data are submitted at separate times, whereas in another embodiment the UI and UED form data are submitted simultaneously. In one embodiment, the UI and UED form data are submitted to separate locations for storage or review, whereas in another embodiment the UI or UED form data are stored or reviewed together. The data may be stored, for instance, in the user's computing device, an external computing device, and/or an external storage medium.

The submitted UI or UED form data, or data from both, are then reviewed by a human, AI or software (or combination) 924. At this stage the UI form template may be modified to account for the data or information provided with the UED form 926, thereby avoiding a repeat of the actual or potential rule violation when the modified UI form is presented in future. The modification to the UI form may, for instance, involve modifying the broken validation rule 928, or modifying the availability or characteristics of data fields 930, to account for inputted data or information and avoid subsequent identical rule violations.

To account for the inputted data, the UED form may be modified as well as, or instead of, the UI form 932. For instance, the UED form template may be modified so that upon a repeat actual or potential rule violation, the UED form automatically populates with data previously inputted into the UED form with respect to the earlier violation 934, or the UED form displays specific new fields relating to the earlier violation 936. (Depending on the design of the system in use, modifications of the UI or UED Forms may be temporary, interim, or permanent.)

On subsequent UI Form use, the modified UI Form and/or UED Form(s) may be used. Repetition of this process allows for the repeated modification and improvement of UI and UED forms as necessary.

FIG. 10 is an exemplary process flow diagram 1000, which shows one embodiment of a method where a User Interface (UI) Form and User Exception Data (UED) Forms and processes may interact, the UI form using inline validation. The methods and systems articulated may allow a User to present non-standard Data into a UI Form or process or related process.

In one instance, it may contain the UI Engine (1002/222) presenting a UI Form (1004/500) to the User; expecting User input or review. Some data may be inserted in the Form before the User begins to enter data. For example, when a User opens a request form, the form may automatically insert that User's name, employee ID, and other data. Those 'auto-filled' fields may be non-editable by the User; but the introduction of UED (1006) may provide the means for a User to edit the data.

The UI Form may contain one or more Operators (520) which may allow the User to call the UED process (1010, 1032, 1037). (Alternatively, the UI Form itself may be altered to allow additional or alternate user data; and may provide a UED record for later review and activity.) A UED Form (1014/600) may be presented which may allow the User to enter data there. The UED Engine (224) may obtain and present UI Form information and data as part of the UED Form (600), in addition to allowing User input to the UED Form. The UED Form may also contain an Operator (e.g. 635) regarding whether employment of the UED should pause or cancel subsequent submission of the UI Form. It (the process flow) may also contain choice 1019 which may, for example, be used to provide design proposals, queries, suggestions, requests, etc. by the User; regarding the UI Form or process itself via 1081 - by allowing User input, without submitting a UI Form.

The preferred embodiment for one implementation may integrate the UI Form Engine and the UED Engine into a unified Engine (e.g. within a software, CRM, database, etc.). However this may not suit all environments; and it is important to note there may be implementations where the UED Forms and processes may act partly or entirely

independently of the UI Form and its associated software(s), databases, processes, etc. (For example: if a UI Form and its accompanying database were not able to be altered in any way, then a UED Engine could be built which might retrieve UI Form information via virtual action - such as screenshot, OCR and/or AI - to 'build' another version of the UI Form in the UED Engine; and thus allow the User to lodge their processing intent, even though it may not match the design or intent of the UI Form originally supplied.)

Data may be inserted into the UI Form by the User: 1020 and 1022. As the User fills the form, some data may be auto-filled in the present field or other UI Form fields; and the introduction of UED operators may provide the means for a User to edit that data also.

Field data may be validated as the User progresses through the UI Form fields. The User may be prompted to edit their data inputs according to path 1025, 1030, 1040.

(Alternatively, in the example where the UI Form itself was modified by the UED call, some or all fields may no longer be validated in this manner.) For data fields which are not validated (1030), the User may choose to call the UED process. The UED record may be created (1032), User input gathered (1034), and the UED record lodged (1036) - before returning to the 1040 check. Near 1032 there may be a flag set regarding whether the UI Form is still valid for submission; and this flag may be used later in the process flow (a likely default value may be set as FALSE, near 1032). At 1040, the User may choose to call a UED process 1037-1038-1039, similar to 1032-1034-1036 (and the flag for this UED instance may likely have a default value set as TRUE, in this case). Note that there may be another flag employed by the process as a whole; which records whether any UED processes were called.

At 1050, the loop back to 1022 may be employed if there are more fields requiring input.

If the instance occurs (1090) where the UI Form has been completed without any UED process calls (1060), then the UI Form may be processed as per the 'normal' UI Form process. (For the purposes of data collection or especially machine learning this data may be gathered by the UED engine or database.) If the instance occurs where at least one UED process has been called (1060), multiple UEDs may be collated (1065). (This may form a 'master' UED record, for example.) Depending on implementations, the decision 1070 may be made by a user, AI, system or software: collectively a User, below.

If the instance occurs where at least one UED process has been called, and the UI Form is still valid for submission, and the User elects to lodge the UI Form for normal processing; then the UI Form may be processed as per the 'normal' UI Form process (1091) and the UED process will be completed as per the User requirements (1082). In some cases, a User may choose to allow processing of the UI Form; and use 1082 to remediate an exception(s).

If the instance occurs where at least one UED process has been called, and the UI Form is deemed not to be valid or suitable for processing, the User may cancel the UI Form processing - and use the UED process to proceed (as per 1080).

FIG. 11 is an exemplary process flow diagram 1100, which shows one embodiment of a method where User Interface (UI) Form data may be recorded and processed using a User Exception Data (UED) Form and process.

Investigation (1110) may be carried out by human, software or AI means to establish the UED process flow.

If the UI Form process may be completed, with (most likely) modified data, then a UED Improvement Process (1130) may be instigated; and the UI Form process may be completed (1140) via normal means. Where the UI Form process may require some modification or intervention, a UED Improvement Process (1160) may be instigated; and the User's intention via the UI Form may be completed (1145). In some cases, the User requirement may not be fulfilled (1190) and a UED process may still be logged (1170) for record and review.

The UED Process flow may also provide collection of multiple UED process calls and information from a single UI Form.

UED data and records may subsequently be used by other UED process calls. For example, suppose a particular field in a UI Form were used to call a UED Process (with accompanying data) and the UED process recorded the subsequent actions to complete the User requirement; then subsequent UED calls on the same field may be provided with those details in order to provide a faster and more accurate resolution - in addition to subsequent UI Form refinements and improvements.

UED data records may be collated prior or during the UED process. There may be varied degrees to which the UI Form Users are involved in the UED process. In some implementations they may be unaware such a process exists; in others they may be involved in all stages; or somewhere in between. Note that 'Users' may include AI in part or wholly, also.

While this invention has been described in connection with specific embodiments thereof, it will be understood that it is capable of further modification(s). The present invention is intended to cover any variations, uses or adaptations of the invention following in general, the principles of the invention and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains and as may be applied to the essential features hereinbefore set forth.

As the present invention may be embodied in several forms without departing from the spirit of the essential characteristics of the invention, it should be understood that the above described embodiments are not to limit the present invention unless otherwise specified, but rather should be construed broadly within the spirit and scope of the invention as defined in the broad consistory statements. Various modifications and equivalent arrangements are intended to be included within the spirit and scope of the invention and consistory statements herein. Therefore, the specific embodiments are to be understood to be illustrative of the many ways in which the principles of the present invention may be practiced.

Where the terms "comprise", "comprises", "comprised" or "comprising" are used in this specification, they are to be interpreted as specifying the presence of the stated features, integers, steps or components referred to, but not to preclude the presence or addition of one or more other features, integers, steps, components to be grouped therewith.