Patent Description:
When contracting with certain employers/clients, a manufacturing or service providing company may be required to abide by, conform to, or otherwise operate in accordance with certain workflows and rules. Exemplary rules may include, but are not limited to, rules specifying jurisdictions in which manufacturing must be done, rules regarding the materials that may be used during manufacturing, rules specifying if the materials must be sourced in a particular location, and rules specifying certain other requirements.

The process of effectively complying with such rules can become very complex when a company is dealing with data structures, each defined by multiple rules, wherein each rule in each data structure may have to be reviewed, approved or implemented by different individuals. For example, one rule may require different department heads within a company to agree or track internal data to comply with the rule. More specifically, if there is a particular manufacturing requirement, the head of logistics, the head of purchasing, and the head of manufacturing, may all need to agree to the rule. Tracking compliance with all the predefined rules in each data structure may become very complicated.

Currently, graphical user interfaces are not designed to effectively and concisely communicate critical information related to the specific workflows which are essential to operationally managing the conformance to rules specifying jurisdictions in which manufacturing must be done, rules regarding the materials that may be used during manufacturing, rules specifying if the materials must be sourced in a particular location, and rules specifying certain other requirements. Such information is often tracked on conventional spreadsheets, fail to communicate the real-time status of workflows, and fail to provide automated follow-ups on outstanding requests.

Hence, there is need for systems and methods that communicate data to individuals within organizations in a manner that improves their ability to ensure compliance with workflows, each defined by a plurality of rules, across several departments. There is also a need for graphical user interfaces that effectively and concisely communicate critical information related to the specific workflows, including data with respect to rules specifying jurisdictions in which manufacturing must be done, rules regarding the materials that may be used during manufacturing, rules specifying if the materials must be sourced in a particular location, rules specifying security requirements, rules specifying remedies in the event of a non-conforming or non-compliant deliverable, and/or rules specifying certain other requirements. There is also a need for graphical user interfaces that communicate the real-time status of workflows and provide automated follow-ups on outstanding requests.

<CIT> discloses an apparatus for managing a workflow includes a workflow processing unit that includes a document generating unit that generates a circular document while setting a flow definition to make an approval route indicating a circulation order in which the circular document is to be circulated, and a transmission definition for a mail for notifying presence of the circular document to a client on the approval route, based on requests from the client, to a prototype in an operation application for generating a circular; and a proxy unit that records requests that relates to the circular document and that are transmitted from the client during circulation of the circular document, and that generates a test scenario in which the requests are arranged following the circulation order.

The following embodiments and aspects thereof are described and illustrated in conjunction with systems, tools and methods, which are meant to be exemplary and illustrative, and not limiting in scope. The present application discloses numerous embodiments.

According to a first aspect of the present invention, there is provided a method according to claim <NUM>.

Optionally, the method further comprises receiving, in a client device, the visually representative data and displaying the visually representative data such that each of the first set of states and second set of states is visually associated with the electronic data structure.

Optionally, the one or more electronically addressable locations comprise an email address, a hardware address, and/or a mobile phone number.

Optionally, the method further comprises using the server to generate data representative of a graphical user interface wherein the graphical user interface is configured to prompt a user to associate at least one of the plurality of different categories with at least one of the plurality of stakeholders.

Optionally, at least one of the first set of states is indicative of at least one of the first subset of the plurality of categories being approved.

Optionally, at least one of the second set of states is indicative of at least one of the second subset of the plurality of categories not being approved.

Optionally, the at least one of the first set of states indicative of being approved is visually distinct from the at least one of the second set of states not being approved.

Optionally, after routing and before receiving input, the method further comprises using the server to send one or more notifications to the at least one of the plurality of stakeholders at the one or more electronically addressable locations.

According to a second aspect of the present invention, there is provided a system according to claim <NUM>.

Optionally, the data that is visually representative of each of the first set of states and second set of states are visually associated with the electronic data structure.

Optionally, the plurality of programmatic instructions, when executed by the at least one processor, is further configured to generate data representative of a graphical user interface wherein the graphical user interface is configured to prompt a user to associate at least one of the plurality of different categories with at least one of the plurality of stakeholders.

Optionally, the plurality of programmatic instructions, when executed by the at least one processor, is further configured to send one or more notifications to the at least one of the plurality of stakeholders at the one or more electronically addressable locations after routing and before receiving the input.

The present specification is directed towards multiple embodiments. The following disclosure is provided in order to enable a person having ordinary skill in the art to practice the invention. Language used in this specification should not be interpreted as a general disavowal of any one specific embodiment or used to limit the claims beyond the meaning of the terms used therein. The general principles defined herein may be applied to other embodiments and applications without departing from the scope of the invention. Also, the terminology and phraseology used is for the purpose of describing exemplary embodiments and should not be considered limiting. Thus, the present invention is to be accorded the widest scope encompassing numerous alternatives, modifications and equivalents consistent with the principles and features disclosed. For purpose of clarity, details relating to technical material that is known in the technical fields related to the invention have not been described in detail so as not to unnecessarily obscure the present invention.

In the description and claims of the application, each of the words "comprise" "include" and "have", and forms thereof, are not necessarily limited to members in a list with which the words may be associated. It should be noted herein that any feature or component described in association with a specific embodiment may be used and implemented with any other embodiment unless clearly indicated otherwise.

As used herein, the indefinite articles "a" and "an" mean "at least one" or "one or more" unless the context clearly dictates otherwise.

<FIG> illustrates an embodiment of a system/environment <NUM> in which a plurality of improved GUIs (Graphical User Interfaces), for distributed rules and workflow management in an organization, are implemented or executed. The system <NUM> comprises client-server architecture, where one or more servers <NUM> are in communication with one or more client devices <NUM> over a network <NUM> such as, for example, an Intranet or the Internet. Users (who may or may not be members of the organization), with predefined roles or user-profiles, access privileges and permission rights, may access the system <NUM> via the one or more client devices <NUM>.

The client devices <NUM> comprise computing devices such as, but not limited to, personal or desktop computers, laptops, Netbooks, handheld devices such as smartphones, tablets, and
the employee's user-profile - that is, approver and/or implementer. The one or more GUIs may be populated with data in accordance with the predefined access privileges and permission rights.

At step <NUM>, a reviewer uses a browser application or a client-side module on his client device <NUM> to log into the at least server <NUM>. At step <NUM>, subsequent to successful logging of the reviewer, the module <NUM> allows the reviewer to access at least a fifth GUI such as, for example, the GUI <NUM> of <FIG> and the data view <NUM> of <FIG> to enable the reviewer to generate at least one review report and add a review note to one or more rules associated with a department.

It should be appreciated that apart from the fifth GUI the reviewer can access a plurality of GUIs to review the first data and the additional data in various ways or views. For example, the reviewer may access the GUIs of <FIG>, <FIG>, <FIG>, and <FIG> as and when needed.

Throughout the workflow, the module <NUM> auto-generates and sends reminders (related to the first data - that is, the rule assigned) to the approvers and implementers based on the type and frequency of reminders configured by the administrator at step <NUM>.

Also, the module <NUM> automatically triggers re-certification (of fulfillment) of the rule through one or more of the above described GUIs.

The above examples are merely illustrative of the many applications of the method of the present specification.

These and other features and advantages of the present specification will be appreciated, as they become better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:.

In accordance with some aspects, the present specification provides methods, and associated graphical user interfaces, that enable individuals within an organization to assign or allocate each of a plurality of rules to at least one organizational entity. In embodiments, the methods, and associated graphical user interfaces, enable each of the individuals within the organizational entity to be notified, via one or more reminders, of the assigned rules and enables the assigned organizational entity to input/record progress notes against the assigned rules. In some embodiments, completion of a rule may entail associating predefined data, indicative of a compliance certificate, with the rule. In embodiments, the methods, and associated graphical user interfaces, automatically enable a triggering of re-certification of rules on a periodic basis.

In an embodiment the present specification provides a method of ensuring that processes, executed by or within a business to manufacture or supply a product or to provide a service, are in conformance with one or more predefined sets of rules.

In an embodiment, the present specification provides a method for enabling a business administrator to maintain a database of predefined sets of rules that may be applied for manufacturing a product or providing a service. In various embodiments, maintaining the database comprises ensuring that said rules are updated with respect to a rule issuing authority.

In an embodiment, the present specification provides a method for enabling a rule approver to determine if the stored rules may be applied for manufacturing a product or providing a service. In an embodiment, the present specification provides a method for enabling a rule implementer to ensure that the stored rules are applied for manufacturing a product or providing a service. In an embodiment, the present specification provides a method for enabling a rule auditor to ensure that the stored rules have been applied for manufacturing a product or providing a service.

In various embodiments, a computing device includes an input/output controller, at least one communications interface and system memory. The system memory includes at least one random access memory (RAM) and at least one read-only memory (ROM). These elements are in communication with a central processing unit (CPU) to enable operation of the computing device. In various embodiments, the computing device may be a conventional standalone computer or alternatively, the functions of the computing device may be distributed across multiple computer systems and architectures.

In some embodiments, execution of a plurality of sequences of programmatic instructions or code enable or cause the CPU of the computing device to perform various functions and processes. In alternate embodiments, hard-wired circuitry may be used in place of, or in combination with, software instructions for implementation of the processes of systems and methods described in this application. Thus, the systems and methods described are not limited to any specific combination of hardware and software.

The term "module", "application" or "engine" used in this disclosure may refer to computer logic utilized to provide a desired functionality, service or operation by programming or controlling a general purpose processor. Stated differently, in some embodiments, a module, application or engine implements a plurality of instructions or programmatic code to cause a general purpose processor to perform one or more functions. In various embodiments, a module, application or engine can be implemented in hardware, firmware, software or any combination thereof. The module, application or engine may be interchangeably used with unit, logic, logical block, component, or circuit, for example. The module, application or engine may be the minimum unit, or part thereof, which performs one or more particular functions.

In embodiments, the term "stakeholder" is used to refer to a human, a group of humans, an organization, or an entity with a particular interest or concern.

The present specification is directed towards multiple embodiments. The following disclosure is provided in order to enable a person having ordinary skill in the art to practice the invention. Language used in this specification should not be interpreted as a general disavowal of any one specific embodiment or used to limit the claims beyond the meaning of the terms used therein. The general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Also, the terminology and phraseology used is for the purpose of describing exemplary embodiments and should not be considered limiting. Thus, the present invention is to be accorded the widest scope encompassing numerous alternatives, modifications and equivalents consistent with the principles and features disclosed. For purpose of clarity, details relating to technical material that is known in the technical fields related to the invention have not been described in detail so as not to unnecessarily obscure the present invention.

The client devices <NUM> comprise computing devices such as, but not limited to, personal or desktop computers, laptops, Netbooks, handheld devices such as smartphones, tablets, and PDAs, and/or any other computing platform known to persons of ordinary skill in the art. Although four client devices <NUM> are illustrated in <FIG>, any number of client devices <NUM> can be in communication with the one or more servers <NUM> over the network <NUM>.

The one or more servers <NUM> can be any computing device having one or more processors and one or more computer-readable storage media such as RAM, hard disk or any other optical or magnetic media. The one or more servers <NUM> include at least one engine or module operating to provide or implement the plurality of improved GUIs along with the workflows of the present specification. In some embodiments, the one or more servers <NUM> may be implemented by a serverless or a cloud of computing platforms operating together as servers <NUM>.

In some embodiments, the one or more servers <NUM> include or are in communication with at least one database system <NUM>. The database system <NUM> described herein may be, include, or interface to, for example, an Oracle™ relational database sold commercially by Oracle Corporation. Other databases, such as Informix™, DB2 (Database <NUM>) or other data storage, including file-based, or query formats, platforms, or resources such as OLAP (On Line Analytical Processing), SQL (Structured Query Language), a SAN (storage area network), Microsoft Access™ or others may also be used, incorporated, or accessed. The database system <NUM> may comprise one or more such databases that reside in one or more physical devices and in one or more physical locations.

In embodiments, the at least one database system <NUM> stores and updates a plurality of data and data associations or inter-relations that are organized using one or more data structures, schemas or tables.

In accordance with aspects of the present specification, the one or more servers <NUM> provide or implement a rules and workflow management engine or module <NUM>. In embodiments, the rules and workflow management module <NUM> executes a plurality of programmatic instructions or code to a) generate a plurality of improved GUIs of the present specification, b) provide access to the plurality of improved GUIs, populated with relevant data, to authorized users via the one or more client devices <NUM>, and c) implement one or more workflows that utilize the plurality of improved GUIs to ensure that various business processes, in the organization, directed towards manufacturing or supplying a product and/or providing a service follow or are in conformance with one or more sets of rules.

In some embodiments, the one or more servers <NUM> also implement a web server in data communication with the rules and workflow management module <NUM>. In such embodiments, the web server is configured to host a rules and workflow management website that provides the plurality of improved GUIs for interactive access using a browser application in each of the one or more client devices <NUM>. Alternatively, in some embodiments, each of the one or more client devices <NUM> is configured to implement or execute a client-side module that operates as a workflow management application. The client-side module is configured to render one or more of the plurality of improved GUIs based on the predefined role, access privilege and profile of a user using the client-side module.

In accordance with some aspects of the present specification, the rules and workflow management module <NUM> differentiates users of the system <NUM> or stakeholders into at least first, second, third and fourth user-profiles, each having predefined roles, access privileges to one or more of the plurality of GUIs and permission rights to view, add and/or delete various data using one or more of the plurality of GUIs, as follows:
At least one first user-profile (hereinafter referred to as an administrator) has access to organization-wide data and GUIs, but is primarily responsible for making sure that the at least one database <NUM> stores a plurality of rules (related or applicable to the business processed of the organization) and keeps them up to date. In some embodiments, the administrator is also responsible for associating each of the plurality of rules with additional data indicative of, for example, department, employee designation, employee name, rule state (first, second or third), regulation, user-profile (of the employee) and reminder type and frequency. In some embodiments, the administrator assigns one or more of the plurality of rules to one or more relevant parts of the organization such as, for example, departments, committees or functional groups.

In some embodiments, for each of the first, second, third and fourth user-profiles (stakeholders), the administrator is responsible for storing and maintaining (in the at least one database <NUM>) predefined roles, access privileges to one or more of the plurality of GUIs and permission rights to view, add and/or delete various data using one or more of the plurality of GUIs.

At least one second user-profile (hereinafter referred to as an approver), an approver, is typically a head of a part of the organization. The approver is responsible for approving whether the organization can abide by each of the one or more rules that have been assigned to his part of the organization (department, for example). In some embodiments, the approver has access to data and GUIs pertaining to his part of the organization. In some embodiments, the approver has access to organization-wide data and GUIs.

At least one third user-profile (hereinafter referred to as an implementer), an implementer, is typically a manager of a part of the organization. The implementer is responsible for ensuring that his part of the organization (department, for example) actually abides by each of the one or more assigned rules.

At least one fourth user-profile (hereinafter referred to as a reviewer or analyzer), a reviewer, is either an employee of the organization or an external third party responsible for checking whether the organization has abided by each of the one or more rules assigned to various parts of the organization.

In embodiments, the administrator uses his client device <NUM> to log into the at least one server <NUM> using his credentials (such as, login ID and password). Consequently, the rules and workflow management engine or module <NUM> presents the administrator with one or more function options in a browser application or a client-side module of his client device <NUM>.

As shown in <FIG>, in some embodiments, the administrator is presented with a GUI 200a displaying a first visual indicator <NUM>, a second visual indicator <NUM> and a third visual indicator <NUM>. The first visual indicator <NUM> when actuated (such as, for example, by clicking using a mouse or by providing a touch based input if the display screen of the administrator's client device <NUM> is touch enabled) by the administrator causes the rules and workflow management module <NUM> to generate a GUI 200b of <FIG> for displaying in the administrator's client device and enabling the administrator to input and store a plurality of rules and additional data. In some embodiments, the GUI 200b is pre-populated with one or more data that is accessed by the module <NUM> from the at least one database <NUM>.

The second visual indicator <NUM> when actuated by the administrator causes the rules and workflow management module <NUM> to generate a GUI 200c of <FIG> for displaying in the administrator's client device and enabling the administrator to view summarized data related to the plurality of rules. In some embodiments, the GUI 200c is pre-populated with one or more data that is accessed by the module <NUM> from the at least one database <NUM>.

The third visual indicator <NUM> when actuated by the administrator causes the rules and workflow management module <NUM> to generate a GUI 200d of <FIG> for displaying in the administrator's client device and enabling the administrator to view a plurality of rules, associated with at least one data structures, such as a contract, along with a state and implementation status corresponding to each of the plurality of rules across various departments. In some embodiments, the GUI 200d is pre-populated with one or more data that is accessed by the module <NUM> from the at least one database <NUM>.

In some embodiments, the GUI 200d is accessible to other user-profiles as well such as the approvers, implementers and/or a reviewer.

Referring now to <FIG>, the GUI 200b presents a first field 210b that allows the administrator to specify a part of an organizational such as, for example, a department (committee, or functional group) to which a rule may be assigned. In some embodiments, the first field 210b is configured as a drop down list of pre-populated organizational departments (committees, or functional groups) that the administrator may select from. For example, the drop down list may include departments such as, but not limited to, manufacturing, hiring, contracts, finance, human resources (HR), law, legal affairs, operations, purchasing, quality assurance (QA), sales, services and travel. A second field 212b allows the administrator to input a rule associated with or assigned to the department selected in the first field 210b. In some embodiments, the second field 212b is configured as a text box. For example, if the administrator selects the department as 'manufacturing' (in the first field 210b) then he may input 'acceptable locations of manufacturing' or 'acceptable materials' as the rule (in the second field 212b).

A third field 214b allows the administrator to specify an employee function, designation or role based on the department selected in the first field 210b. In some embodiments, the third field 214b is configured as a drop down list of pre-populated employee functions, designations or roles. For example, if the administrator selects the department as 'HR' (in the first field 210b) then the third field 214b may automatically show Head of HR, Head of Training and Development, HR Manager, Training and Development Manager and Compensation and Benefits Manager in the drop down list.

A fourth field 216b allows the administrator to specify an employee name based on the employee function, designation or role selected in the third field 214b. In some embodiments, the fourth field 216b is configured as a drop down list of pre-populated executives/managers related to the employee function, designation or role selected in the third field 214b. For example, if the administrator selects the employee function, designation or role as HR manager (in the third field 214b), the fourth field 216b may automatically show various HR manager names to select from. A fifth field 218b allows the administrator to specify one of a first, second or third state of the rule input in the second field 212b. In some embodiments, the fifth field 218b is configured as a drop down list of pre-populated first, second and third states to choose from. In some embodiments, the first state corresponds to a rule being approved, accepted or implemented, the second state corresponds to a rule being denied - that is, not approved, accepted or implemented and the third state corresponds to a rule requiring analyses to decide full, partial or no approval, acceptance or implementation of the rule. In some embodiments, the first, second and third states are described using textual data. In some embodiments, the first, second and third states are communicated using visual icons such as, for example, a green colored dot indicative of the first state, a red colored dot being indicative of the second state and a yellow colored dot being indicative of the third state. In various embodiments, the visual icons could be of different shapes, sizes, colors, textures, orientations, blink rates, imagery (inanimate or animate) and/or other visual traits.

It should be appreciated that the number of fields, in the GUI 200b, may vary in different embodiments. For example, in some embodiments, the GUI 200b may further include a sixth field 220b that allows the administrator to specify a guideline, directive or regulation on which the rule in the second field 212b relates to. In some embodiments, the sixth field 220b is configured as a drop down list of pre-populated regulations. For example, the rule may be related to a guideline, directive or regulation such as, but not limited to, Corporate Governance, HSAR (Homeland Security Acquisition Regulation), Corporate Social Responsibility, DFARS (Defense Federal Acquisition Regulation Supplement), Work Ethics, FAR (Federal Acquisition Regulation), and Team Culture.

In some embodiments, the GUI 200b further includes a seventh field 222b that allows the administrator to specify a user-profile - that is, whether the employee specified in the fourth field 216b is designated or authorized as an approver, implementer or reviewer of the rule (input in the second field 212b). In some embodiments, the seventh field 222b is configured as a group of first, second and third check-boxes such that checking the first check-box indicates that the employee is authorized as an approver, checking the second check-box indicates that the employee is authorized as an implementer and checking the third check-box indicates that the employee is authorized as a reviewer. In some embodiments, checking both the first and second check-boxes indicates that the employee is authorized both as an approver and an implementer. However, in some embodiments, an employee who is designated as an approver, implementer or both may not be also designated as a reviewer. Accordingly, if the first and/or second check-boxes are checked, the GUI 200b is configured to automatically disable the third check-box. Similarly, in some embodiments, an employee who is designated as a reviewer may not be also designated as an approver and/or an implementer. Accordingly, if the third check-box is checked, the GUI 200b is configured to automatically disable the first and second check-boxes. Stated differently, in some embodiments, it is preferred that a reviewer is not the same person who is tasked with the roles and responsibilities of an approver and/or implementer.

As discussed earlier in the specification, the administrator is responsible for storing and maintaining (in the at least one database <NUM>) predefined roles, access privileges to one or more of the plurality of GUIs and permission rights to view, add and/or delete various data using one or more of the plurality of GUIs. Accordingly, when the administrator designates an employee as approver or implementer, approver and implementer, or reviewer the module <NUM> automatically accesses the corresponding predefined role, access privileges and permission rights from the at least one database <NUM> and assigns them to the employee.

In some embodiments, the GUI 200b further includes an eighth group of fields 223b that allows the administrator to configure a type and frequency of reminders or messages to be automatically generated and sent (by the module <NUM>) to the employee (mentioned in the fourth field 216b). Thus, in some embodiments, first and second check-boxes 223b' allow the administrator to choose email and/or SMS as types of reminders while a drop-down list 223b" allows the administrator to choose a frequency from a plurality of predefined reminder frequencies or periodicities. In various embodiments, the reminder frequencies may range from, for example, daily, alternate days, bi-week, weekly, fortnightly or monthly. In embodiments, a choice of the reminder frequency may be dependent on a user-profile (approver, implementer, or reviewer) of the employee and/or urgency of implementation of the rule. For example, if the rule is critical to a business process and requires urgent certification of completion/implementation, the administrator may choose a more frequent reminder option such as, say, daily. In embodiments, the automatically generated reminders or messages may be turned off, or otherwise terminated, by the administrator or by virtue of the employee having met one or more requirements. Upon meeting the one or more requirements, the reminder or message is automatically terminated without further action by the administrator or employee.

In some embodiments, the GUI 200b further includes a ninth field 224b that allows the administrator to configure a frequency or periodicity at which a certificate of implementation or fulfillment of the rule (in the second field 212b) must be obtained. Based on the frequency or periodicity, the module <NUM> automatically enables a triggering of re-certification of the rule. In some embodiments, the ninth field 224b is configured as a pre-populated drop-down list. In embodiments, the re-certification frequency or periodicity may range in months and years.

Once, the administrator has input his responses in the first, second, third, fourth, fifth, sixth, seventh, eighth and ninth fields 210b, 212b, 214b, 216b, 218b, 220b, 222b, 223b and 224b he may click on the 'save' button 225b to store the input rule and associated data including the department, employee designation, employee name, state, regulation, user-profile and reminders in the at least one database <NUM>. Stated differently, the rule is associated with the type of rule or department, employee designation or role, employee name, state, regulation, user-profile and reminders. This association results in the rule being automatically assigned to a specific department, designation/role and employee, manager or executive within the organization for further approval, implementation or review.

In embodiments, consequent to saving the input rule and associated data, a reminder or message is auto-generated by the module <NUM> and sent to the employee (of the fourth field 216b) prompting him to review the applicable rule and establish the organization's position - that is, approve, deny or analyze to decide full, partial or no approval of the rule.

It should be appreciated that the drop down lists of the first, third, fourth, fifth, sixth and ninth fields 210b, 214b, 216b, 218b, 220b (as well as the reminder frequency field 223b'') and 224b are pre-populated with related data pre-stored and accessed from the at least one database <NUM>.

In some embodiments, the GUI 200c enables the administrator to view summarized data associated with a plurality of rules input and stored using the GUI 200b. In embodiments, the GUI 200c is generated by the rules and workflow management module <NUM> and is populated with a plurality of data that is accessed (by the rules and workflow management module <NUM>) from the at least one database <NUM> and processed, for display, if required. Referring now to <FIG>, in some embodiments, the GUI 200c displays recently added rule(s) in a first visual grid 210c, count of rules by first, second and third states in a second visual grid 220c and various parts of an organization such as, for example, departments, roles or functions in a third visual grid 230c. The first visual grid 210c includes a plurality of rows and columns. A first column 212c displays data indicative of one or more recently added rule(s) 213c in respective one or more rows 214c. In some embodiments, all rules added by the administrator in the recent, say, N days, are displayed. In some embodiments, N ranges from <NUM> day to <NUM> days and preferably <NUM> days. As a non-limiting example, the first visual grid 210c shows a single recently added rule 213c in a first row 214c. In some embodiments, the displayed rule 213c is hyperlinked which when clicked may generate another GUI to display further details, notes or explanations related the rule, associated data and/or relevant documentation describing details and sub-rules that may be accessed from the at least one database <NUM>. A second column 215c displays an alternate method of referring to the displayed rule 213c. A third column 216c displays data indicative of a regulation or authority associated with each of the rules 213c. A fourth column 217c displays data indicative of a state (first, second or third) associated with each of the rules 213c. A fifth column 218c displays data indicative of the workflow. A sixth column 219c displays data indicative of a status of active or inactive associated with each of the rules 213c, such as whether the rule is actively being applied, and therefore must be adhered to, or not active and need not be considered. Each X data, regulation data, state data, Y data and status data is visually aligned, horizontally, in each row, with the associated rule 213c. For example, the rule 213c in the first row 214c is visually aligned, horizontally, with X data, regulation, the first state indicative of the rule being always approved or implemented, Y data, and an active status. In some embodiments, data in the first visual grid 210c may be sorted, in ascending or descending order, with respect to data in any of the columns.

The second visual grid 220c displays data indicative of a count of rules by regulations and states (first, second and third states). In some embodiments, the grid 220c includes a first column 221c that displays one or more regulations in respective one or more rows, a second column 222c that displays a total count of rules (across the first, second and third states) related to each of the regulations, a third column 223c that displays a count of rules associated with the second state, a fourth column 224c that displays a count of rules associated with the first state and a fifth column 225c that displays a count of rules associated with the third state.

Data in each of the second, third, fourth and fifth columns 222c, 223c, 224c and 225c is visually aligned, horizontally, in each row, with the associated regulation in the first column 221c. For example, the first row 226c displays that for a particular contract or regulation (first column 221c) there are a total of <NUM> rules (second column 222c) of which <NUM> rules are of the second state (third column 223c), <NUM> rules are of the first state (fourth column 224c) and <NUM> rules are of the third state (fifth column 225c). A final row 227c provides, in the second column 222c - a grand total of the count of all rules related to all regulations, in the third column 223c - a grand total of the count of all second state rules related to all regulations, in the fourth column 224c - a grand total of the count of all first state rules related to all regulations, and in the fifth column 225c - a grand total of the count of all third state rules related to all regulations.

The second visual grid 230c displays data related to various departments, roles or functions as accessed from the at least one database <NUM>. In some embodiments, the grid 230c includes a first column 232c that displays a plurality of departments, roles or functions of the organization in a plurality of respective rows 233c. A second column 235c displays names of a plurality of managers/executives in the plurality of rows 233c such that each manager/executive is visually aligned, horizontally, in each row, with the associated department, role or function. A third column 238c displays a number of users logged into the system <NUM> from each of the department, role or function.

As discussed earlier, with reference to GUI 200b, as a result of the administrator's data inputs each rule is associated with at least the department, employee designation or role, employee name, rule state (first, second or third), regulation and user-profile. This association results in each rule being automatically assigned to a specific department, designation/role and employee, manager or executive within the organization for further approval/review and implementation. Accordingly, the GUI 200d displays a visual grid 202d that presents an association of each rule with a department along with a state and implementation status. In embodiments, the GUI 200d is generated by the rules and workflow management module <NUM> and is populated with a plurality of data that is accessed (by the rules and workflow management module <NUM>) from the at least one database <NUM> and processed for display, if required.

It should be appreciated that, in some embodiments, the data view of the GUI 200d is not only accessible to the administrator but also to other organizational entities or executives depending upon their role/designation. Thus, in some embodiments, along with the administrator all entities or executives designated or authorized as approvers and implementers may also access the data view of the GUI 200d by logging into the at least one server <NUM> from their respective client devices <NUM>. In some embodiments, along with the administrator all entities or executives designated or authorized as approvers may access the data view of the GUI 200d. In some embodiments, all entities or executives designated or authorized as approvers and implementers may also access the data view of the GUI 200d while the administrator may not be authorized to access the GUI 200d. In some preferred embodiments, the data view of the GUI 200d is accessible to the administrator and approvers but not to implementers. Additionally, in some embodiments, at least one reviewer (who may be an entity internal or external to the organization) may also have the necessary permissions to access the data view of the GUI 200d in order to conduct a review process.

Referring now to <FIG>, the visual grid 202d includes a plurality of rows and columns. A first column 204d displays data indicative of one or more rules in respective one or more rows 206d. In some embodiments, each of the displayed rules is hyperlinked which when clicked may generate another GUI to display further details, notes or explanations related to the rule, associated data and/or relevant documentation describing details and sub-rules that may be accessed from the at least one database <NUM>.

A second column 208d displays data indicative of the first, second or third state associated with each of the one or more rules. In some embodiments, a state associated with a rule initially depends on the state input by the administrator through the fifth field 218b of GUI 200b. However, in some embodiments, the state may be modified (to another state) by an approver (who may or may not be the same as an implementer) and therefore the second column 208d reflects the most recent first, second or third state. In some embodiments, any of the first, second or third state may be modified from one state to another. In some embodiments, not all types of states may be allowed to be modified by the approver. For example, in some embodiments, only the third state (corresponding to a rule requiring analyses to decide full, partial or no acceptance/implementation of the rule) may be modified to the first or second state by an approver.

The second column 208d is followed by a plurality of columns wherein each column is dedicated to a department, role or function and displays data indicative of a role implementation status related to one or more actions pertaining to a rule. In some embodiments, third, fourth, fifth, sixth, seventh, eighth, ninth, tenth, eleventh, twelfth, thirteenth, fourteenth, fifteenth, sixteenth, seventeenth, eighteenth, nineteenth and twentieth columns 210d, 211d, 212d, 213d, 214d, 215d, 216d, 217d, 218d, 219d, 220d, <NUM>, 222d, 223d, 224d, 225d, 226d and 227d are dedicated, respectively, to the departments, roles or functions (such as those shown in the second visual grid 230c of <FIG>). Each of these columns related to the departments, roles or functions displays data indicative of the rule implementation status - that is, whether a rule, and therefore any task(s) associated with the rule, assigned to a department has been followed, fulfilled, abided by or adhered to. Thus, the data indicative of the rule implementation status changes depending on a progress being made and logged into the system by a department, role or function, with respect to a rule assigned to the department, role or function.

In various embodiments, the data indicative of the rule implementation status may communicate a) if the rule has been implemented (first rule implementation status), b) if the rule has not been implemented and no progress has been made on its implementation (second rule implementation status) or c) if implementation of the rule is in-progress (third rule implementation status). In some embodiments, the data indicative of the rule implementation status is a certificate of implementation or fulfillment of the rule.

In some embodiments, the data indicative of the rule implementation status is visually communicated, through the visual grid 202d, by way of a visual icon. In various embodiments, the visual icon could be of different shapes, sizes, colors, textures, orientations, blink rates, imagery (inanimate or animate) and/or other visual traits. As non-limiting examples, in some embodiments, the visual icon could be a tick-mark icon representative of the first rule implementation status, a cross-mark icon representative of the second rule implementation status and a clock icon representative of the third rule implementation status. In some embodiments, the visual icon could be a progress-bar icon which when fully colored in, say, green is representative of the first rule implementation status, when partially colored in green (or, say, yellow color) is representative of the second rule implementation status and when fully colored in, say, red or when fully colored in white is representative of the third rule implementation status.

In various embodiments, the data indicative of the rule implementation status is displayed in a cell of the visual grid 202d, wherein the cell is defined by an intersection of a column and a row and is visually aligned, horizontally (in a row), with a rule. For example, as shown in the visual grid 202d, for a rule titled "certificate of independent price determination" (in second row 206d<NUM>) a cell 230d displays a visual icon representative of the first rule implementation status. The cell 230d is defined by an intersection of the fifth column 212d (Finance department) and the second row 206d<NUM> and is visually aligned, horizontally, with the rule in the second row 206d<NUM>. Similarly, each of the cell 231d, 232d and 233d also displays a visual icon representative of the first rule implementation status. The cell 231d is defined by an intersection of the seventeenth column 224d (Science and Technology department) and the second row 206d<NUM>, cell 232d is defined by an intersection of the eighteenth column 225d (Sales department) and the second row 206d<NUM>, and cell 233d is defined by an intersection of the nineteenth column 226d (Services department) and the second row 206d<NUM>. Each of the cell 231d, 232d and 233d is visually aligned, horizontally, with the rule in the second row 206d<NUM>.

In another example, as shown in the visual grid 202d, for a rule titled "Gratuities" " (in third row 206d<NUM>) a cell 235d displays a visual icon representative of the third rule implementation status. The cell 235d is defined by an intersection of the sixth column 213d (HR (C) department) and the third row 206d<NUM> and is visually aligned, horizontally, with the rule in the third row 206d<NUM>. Further, a cell 236d displays a visual icon representative of the first rule implementation status. The cell 236d is defined by an intersection of the seventh column 214d (HR (D) department) and the third row 206d<NUM> and is visually aligned, horizontally, with the rule in the third row 206d<NUM>.

In some embodiments, data in the visual grid 202d may be sorted, in ascending or descending order, with respect to data in any of the columns 204d, 208d, 210d, 211d, 212d, 213d, 214d, 215d, 216d, 217d, 218d, 219d, 220d, <NUM>, 222d, 223d, 224d, 225d, 226d and 227d.

In some embodiments, data in the visual grid 202d may be filtered using at least one or any combination of first, second and third criteria, wherein the first criterion is that of a regulation (to which a rule may be related to or associated with) and is actuated using a first field 240d, the second criterion is that of a status of the rule (first, second or third status) and is actuated using a second field 242d, and the third criterion is that of a department (to which a rule may have been assigned to) and is actuated using a third field 244d. In some embodiments, each of the first, second and third field 240d, 242d and 244d is configured as a drop-down list of pre-populated data. In some embodiments, data in the visual grid 202d may be searched on the basis of a specific rule using a fourth field 246d configured as a text box.

<FIG> shows an exemplary GUI <NUM> communicating a plurality of data related to outstanding certifications indicative of rules that are pending implementation, in accordance with some embodiments of the present specification. In embodiments, the GUI <NUM> is generated by the rules and workflow management module <NUM> and is populated with the plurality of data that is accessed (by the rules and workflow management module <NUM>) from the at least one database <NUM> and processed for display, if required. In some embodiments, the GUI <NUM> displays a visual grid <NUM> having a plurality of columns populated with data related to one or more rules for which a certificate of implementation is pending.

In embodiments, the data view of the GUI <NUM> is accessible to the administrator, approvers and/or implementers depending upon access permissions granted by the administrator based on an organizational protocol. For example, in some embodiments, in addition to the administrator, a Department Head (as an approver) may have access to the GUI <NUM>. Specifically, since the exemplary data in the GUI <NUM> pertains to the HR department, a Department Head of HR may have access. Additionally, in some embodiments, at least one HR Manager (as implementer) may also have access to the GUI <NUM>. It should be appreciated that certain executives who have organization wide roles and responsibilities, such as the C-suite executives and the Board of Directors, may also have access to the GUI 400a.

As shown in the visual grid <NUM>, a first column <NUM> displays first data indicative of one or more rules for which a certificate of implementation is pending or outstanding. Each of the one or more rules is presented in a respective row <NUM>. A second column <NUM> displays second data indicative of the department that is responsible for implementing each of the one or more rules. A third column <NUM> displays third data indicative of one or more tasks or requirements that must be fulfilled in order to receive a certificate of completion or fulfillment for each of the one or more rules. A fourth column <NUM> displays fourth data indicative of a time period for which each of the one or more rule is pending completion or fulfillment. In some embodiments, the time period is expressed in number of days. However, in alternate embodiments, the time period may be expressed in weeks, fortnights or months. A fifth column <NUM> displays fifth data indicative of whether each of the one or more rules is certified as having been completed or fulfilled.

In various embodiments, each of the first, second, third, fourth and fifth data is displayed in a cell of the visual grid <NUM>, wherein the cell is defined by an intersection of a column and a row and is visually aligned, horizontally (in a row), with a rule. For example, as shown in the visual grid <NUM>, for a rule titled "gratuities" (in first row <NUM><NUM>) a cell <NUM><NUM> displays the second data. The cell <NUM><NUM> is defined by an intersection of the second column <NUM> (department) and the first row <NUM><NUM> and is visually aligned, horizontally, with the rule in the first row <NUM><NUM>. Similarly, cells <NUM><NUM>, <NUM><NUM>, <NUM><NUM> respectively display the third, fourth and fifth data. The cell <NUM><NUM> is defined by an intersection of the third column <NUM> and the first row <NUM><NUM>, cell <NUM><NUM> is defined by an intersection of the fourth column <NUM> and the first row <NUM><NUM>, and cell <NUM><NUM> is defined by an intersection of the fifth column <NUM> and the first row <NUM><NUM>. Each of the cells <NUM><NUM>, <NUM><NUM>, <NUM><NUM> is visually aligned, horizontally, with the rule ("gratuities") in the first row <NUM><NUM>.

As an exemplary illustration, the visual grid <NUM> displays all rules that are pending completion for the HR (C) department. In some embodiments, the visual grid <NUM> is configured to filter and display rules that are pending completion for a particular department, role or function in the organization. In some embodiments, the visual grid <NUM> may be configured to display rules that are pending completion for all departments, roles or functions in the organization.

<FIG> shows an exemplary GUI 400a communicating a first plurality of data related to one or more data structures, such as contracts, in accordance with some embodiments of the present specification. In embodiments, the GUI 400a is generated by the rules and workflow management module <NUM> and is populated with the first plurality of data that is accessed (by the rules and workflow management module <NUM>) from the at least one database <NUM> and processed for display, if required. In some embodiments, the GUI 400a displays a visual grid 401a having a plurality of columns populated with data related to one or more contracts.

In embodiments, the data view of the GUI 400a is accessible to the administrator, approvers and/or implementers depending upon access permissions granted by the administrator and based on an organizational protocol. For example, in some embodiments, in addition to the administrator, a Department Head (as approver) may also have access to the GUI 400a. Specifically, since the exemplary data in the GUI 400a pertains to the Contracts Department, a Department Head of Contracts (as the approver) may have access. Additionally, in some embodiments, at least one Contracts Manager (as implementer) may also have access to the GUI 400a. It should be appreciated that certain executives who have organization wide roles and responsibilities, such as the C-suite executives and the Board of Directors, may also have access to the GUI 400a.

As shown in the visual grid 401a, a third column <NUM> displays third data indicative of one or more data structures, such as contracts, each of the one or more contracts being presented in a respective row <NUM>. A first column <NUM> displays first data indicative of a serial number or ID (Identification) for each of the one or more contracts. A second column <NUM> displays second data indicative of a first or second approval status for each of the one or more contracts. The first approval status corresponds to an approval being denied or refused and the second approval status corresponds to an approval being granted. In some embodiments, the second data is visually communicated, through the visual grid 401a, by way of a visual icon and/or textual data. In various embodiments, the visual icon could be of different shapes, sizes, colors, textures, orientations, blink rates, imagery (inanimate or animate) and/or other visual traits. As non-limiting examples, in some embodiments, the visual icon could be a tick-mark icon representative of the first approval status and a cross-mark icon representative of the second approval status. Alternatively, in some embodiments, the textual data could simply be an "approved" text representative of the first approval status and a "disapproved" text representative of the second approval status.

A fourth column <NUM> displays fourth data indicative a customer name or ID corresponding to each of the one or more contracts. A fifth column <NUM> displays fifth data indicative of a monetary value of each of the one or more contracts. A sixth column <NUM> displays sixth data indicative of a project name of each of the one or more contracts. A seventh column <NUM> displays seventh data indicative of an executive, such as, for example, a contract manager, assigned to each of the one or more contracts. An eighth column <NUM> displays eighth data indicative of a date of creation of each of the one or more contracts. A ninth column <NUM> displays ninth data indicative of a date of submission corresponding to each of the one or more contracts. A tenth column <NUM> displays tenth data indicative of a 'saved' or 'submitted' status corresponding to each of the one or more contracts. An eleventh column <NUM> displays eleventh data corresponding to each of the one or more contracts. In some embodiments, the eleventh data includes first, second, third and fourth icons 422a, 422b, 422c and 422d each of which being related to a function that is executed, on the data in the visual grid 401a, as a result of a user actuating (for example, by clicking) an icon.

In various embodiments, each of the first, second, third, fourth, fifth, sixth, seventh, eighth, ninth, tenth and eleventh data is displayed in a cell of the visual grid 401a, wherein the cell is defined by an intersection of a column and a row and is visually aligned, horizontally (in a row), with a contract. For example, as shown in the visual grid 401a, for a contract titled "Annual Reps and Certs" (in second row <NUM><NUM>) a cell <NUM><NUM> displays the seventh data. The cell <NUM><NUM> is defined by an intersection of the seventh column <NUM> (assigned executive name) and the second row <NUM><NUM> and is visually aligned, horizontally, with the contract in the second row <NUM><NUM>. Similarly, as further illustration, cells <NUM><NUM>, <NUM><NUM>, <NUM><NUM> respectively display the second, fourth and fifth data. The cell <NUM><NUM> is defined by an intersection of the second column <NUM> and the second row <NUM><NUM>, cell <NUM><NUM> is defined by an intersection of the fourth column <NUM> and the second row <NUM><NUM>, and cell <NUM><NUM> is defined by an intersection of the fifth column <NUM> and the second row <NUM><NUM>. Each of the cell <NUM><NUM>, <NUM><NUM>, <NUM><NUM> is visually aligned, horizontally, with the contract ("Annual Reps and Certs") in the second row <NUM><NUM>.

A virtual button <NUM> when actuated enables the user to create and add data related to a new contract record for addition to the visual grid 401a. A search field <NUM> enables the user to search for data related to specific contracts within the visual grid 401a. The user can further specify to search contracts that are current <NUM> (that is, the ones that have been created or submitted within a predefined period of time such as, for example, within a year) or archived <NUM>. Data displayed in the visual grid 401a can be further downloaded in Excel or PDF formats by actuation icons <NUM>, <NUM> respectively.

<FIG> shows an exemplary GUI 400b communicating a second plurality of data with reference to one of the one or more contracts (displayed in GUI 400a), in accordance with some embodiments of the present specification. In embodiments, the GUI 400b is generated by the rules and workflow management module <NUM> and is populated with the second plurality of data that is accessed (by the rules and workflow management module <NUM>) from the at least one database <NUM> and processed for display, if required. In some embodiments, the GUI 400b displays a visual grid 401b having a plurality of columns showing data related to one of the one or more contracts.

In embodiments, the data view of the GUI 400b is accessible to the administrator, approvers and/or implementers depending upon access permissions granted by the administrator based on an organizational protocol. For example, in some embodiments, in addition to the administrator, a Department Head (as approver) may also have access to the GUI 400b. Specifically, since the exemplary data in the GUI 400a pertains to the Contracts department, a Department Head of Contracts (as the approver) may have access. Additionally, in some embodiments, at least one Contracts Manager (as implementer) may also have access to the GUI 400b. It should be appreciated that certain executives who have organization wide roles and responsibilities, such as the C-suite executives and the Board of Directors, may also have access to the GUI 400b.

In some embodiments, the GUI 400b is generated when the user clicks on data indicative of any one of the contract records displayed in the GUI 400a. For example, if the user clicks in cell <NUM><NUM> (or in any cell of the second row <NUM><NUM>) then the GUI 400b is presented to the user with data related to the contract titled "Annual Reps and Certs" (in the second row <NUM><NUM> of GUI 400a).

Referring now to <FIG>, the GUI 400b has a first region <NUM> and a second region <NUM>. The first region <NUM> displays a first field <NUM> with a title of a contract to which the GUI 400b pertains to, a second field <NUM> with a customer name associated with the contract, a third field <NUM> identifying an end user, a fourth field <NUM> with a monetary value associated with the contract, a fifth field <NUM> with a project/program name associated with the contract, a sixth field <NUM> with the name of an executive, such as, for example, a contract manager, to whom the contract has been assigned to for overall fulfillment and completion, a seventh field <NUM> for displaying textual notes associated with the contract, an eighth field <NUM> identifying a business process to which the contract is associated with - for example, the contract titled "Annual Reps and Certs" is associated with a service process of a threat detection product, a ninth field <NUM> with the name of an additional approver and a tenth field <NUM> identifying an email ID of the additional approver.

The second region <NUM> presents data in a visual grid 401b. As shown in the visual grid 401b, a second column <NUM> displays second data indicative of one or more rules associated with the contract, each of the one or more rules being presented in a respective row <NUM>. In various embodiments, the one or more rules are associated with the contract by the administrator, approver and/or implementer and the association is stored in the at least one database <NUM>. A first column <NUM> displays first data indicative of a unique ID associated with each of the one or more rules. A third column <NUM> displays third data indicative of a version date corresponding to each of the one or more rules. A fourth column <NUM> displays fourth data indicative of one of the first, second or third state associated with each of the one or more rules.

A fifth column <NUM> displays fifth data indicative of one or more departments to which each of the one or more rules are assigned. For example, a rule titled "certificate of independent price determination" in the first row <NUM><NUM> has been assigned to first and second departments <NUM>, <NUM> (in the fifth column <NUM>), wherein the first department <NUM> is, say, finance and the second department <NUM> is, say, services. In some embodiments, the fifth data is presented in the form of a visual icon and/or textual data for each of the one or more departments. In various embodiments, the visual icon could be of different shapes, sizes, colors, textures, orientations, blink rates, imagery (inanimate or animate) and/or other visual traits.

As non-limiting examples, in some embodiments, each of the first and second departments <NUM>, <NUM> is represented with a green colored visual icon bearing the name of the department (finance and services, in this case). In some embodiments, a color of the visual icon is indicative of one of a first, second or third implementation status of the assigned rule (displayed in the second column <NUM>). Thus, as an example, a green color is indicative of the first implementation status signifying that the rule has been implemented or fulfilled, a yellow color is indicative of the second implementation status signifying that implementation of the rule is in-progress, whereas a red color is indicative of the third implementation status signifying that the rule has not been implemented and no progress has been made on its implementation.

A sixth column <NUM> displays sixth data indicative of whether or not one or more reminders have been sent to a department (of the fifth column <NUM>) to which a rule (of the second column <NUM>) has been assigned. In some embodiments, the sixth data is presented in the form of a visual icon and/or textual data. In some embodiments, the visual icon could represent an email icon signifying that an email reminder. In some embodiments, the textual data could represent a text "email reminder sent dated mm/dd/yyyy". As an example, a rule titled "authorization to perform" in the tenth row <NUM><NUM> has been assigned to first and second departments <NUM>, <NUM> (in the fifth column <NUM>), wherein the first department <NUM> is shown in red (indicative of the third implementation status) and the second department <NUM> is shown in green (indicative of the first implementation status). Consequently, the sixth column <NUM> shows an email icon <NUM> signifying that at least one email reminder has been sent to the first department <NUM> that has made no progress on the rule in the tenth row <NUM><NUM>. In some embodiments, the email icon <NUM> when clicked allows the user to view contents of the at least one email reminder.

In various embodiments, each of the first, second, third, fourth, fifth and sixth data is displayed in a cell of the visual grid 401b, wherein the cell is defined by an intersection of a column and a row and is visually aligned, horizontally (in a row), with a rule in the second column <NUM>. For example, as shown in the visual grid 401b, for the rule titled "certificate of independent price determination" (in the first row <NUM><NUM>) a cell <NUM> displays visual icons corresponding to the first and second departments <NUM>, <NUM> (in the fifth column <NUM>). The cell <NUM> is defined by an intersection of the fifth column <NUM> (for departments) and the first row <NUM><NUM> and is visually aligned, horizontally, with the rule in the first row <NUM><NUM>.

In some embodiments, an eleventh field <NUM> allows the user to filter data in the visual grid 401b based on a regulation selected from a drop-down list of regulations. A twelfth field <NUM> allows the user to search specific data in the visual grid 401b.

In some embodiments, a first button <NUM> when clicked allows the user to generate a second set of records comprising a copy of the data related to the contract ("Annual Reps and Certs") being currently displayed in the GUI 400b. This functionality is advantageous and convenient for the user when new contract records are required to be generated, data for which are broadly similar to those of an existing contract. With a single click on the first button <NUM>, the user can replicate existing contract data to generate new contract data. If required, the so generated new contract data may be quickly edited with respect to rules.

In some embodiments, a second button <NUM> when clicked allows the user to export the data in a first format. Third and fourth buttons 484a, 484b when clicked allows the user to save any changes that have been made to the data displayed in the GUI 400b. In some embodiments, a fifth button <NUM> when clicked allows the user to export the data in a second format. A sixth button <NUM> when clicked allows the user to cancel working on and exit the GUI 400b.

In accordance with aspects of the present specification, at least one reviewer, internal or external to the organization, may be designated and authorized by (the administrator) to review implementation or fulfillment status of various rules by various concerned departments. In some embodiments, the at least one reviewer is a third-party responsible for conducting a review process at a predefined frequency or periodicity. The at least one reviewer is provided necessary permissions (by the administrator) within the system <NUM> to be able to access relevant data and GUIs required to conduct the review process and generate one or more review reports.

<FIG> shows an exemplary GUI <NUM> accessible to a reviewer in order to generate a review report, in accordance with some embodiments of the present specification. In embodiments, the GUI <NUM> is generated by the rules and workflow management module <NUM> and is populated with data that is accessed (by the rules and workflow management module <NUM>) from the at least one database <NUM> and processed for display, if required.

In embodiments, the GUI <NUM> has a first region <NUM> and a second region <NUM>. The first region <NUM> displays a first field <NUM>, configured as a text box, to enable the reviewer to input a title of the review report corresponding to the data in the second region <NUM>. Second and third fields <NUM>, <NUM> are, respectively, automatically populated with the name of the reviewer (who is accessing the data view of the GUI <NUM>) and a date of creation/generation of the review report. In some embodiments, the second and third fields <NUM>, <NUM> cannot be edited or modified by the reviewer.

In some embodiments, the GUI <NUM> may further include a fourth field <NUM> that allows the reviewer to filter the data in the second region <NUM> based on a regulation. In some embodiments, the fourth field <NUM> is configured as a drop down list of pre-populated regulations. A fifth field <NUM> enables the reviewer to search data in the second region <NUM> based on a rule.

In some embodiments, the second region <NUM> displays the visual grid 202d of <FIG> populated with data indicative of a plurality of rules, associated with at least one contract, and their corresponding first, second or third state as well as review/implementation status across departments responsible for each of the plurality of rules. As discussed earlier in this specification, the visual grid 202d displays the data in the first, second third, fourth, fifth, sixth, seventh, eighth, ninth, tenth, eleventh, twelfth, thirteenth, fourteenth, fifteenth, sixteenth, seventeenth, eighteenth, nineteenth and twentieth columns 204d, 208d, 210d, 211d, 212d, 213d, 214d, 215d, 216d, 217d, 218d, 219d, 220d, <NUM>, 222d, 223d, 224d, 225d, 226d and 227d.

<FIG> shows a data view <NUM> accessible, in some embodiments, through the exemplary GUI <NUM> to enable the reviewer to add a review note to one or more rules associated with a department, in accordance with some embodiments of the present specification. Referring to <FIG> and <FIG>, in some embodiments, the reviewer can multi-click (for example, double-click) on a plurality of data record cells (vertical cells) under any one of the department columns (third, fourth, fifth, sixth, seventh, eighth, ninth, tenth, eleventh, twelfth, thirteenth, fourteenth, fifteenth, sixteenth, seventeenth, eighteenth, nineteenth and twentieth columns 210d, 211d, 212d, 213d, 214d, 215d, 216d, 217d, 218d, 219d, 220d, <NUM>, 222d, 223d, 224d, 225d, 226d and 227d) to select multiple data record cells and to generate the data view <NUM> specific to the department and the rules associated with the selected multiple data record cells (vertical cells). As a non-limiting example, the reviewer may double-click and select the data record cells <NUM><NUM>, <NUM><NUM>, and <NUM><NUM> (associated with the fourth column 211d of the Contracts departments) as a result of which the reviewer is presented with the data view <NUM> that presents data indicative of the rules 204d<NUM>, 204d<NUM> and 204d<NUM> associated with the Contracts department.

Alternatively, in some embodiments, the reviewer can single-click on a single data record cell under any one of the department columns to select the single data record cell and to generate the data view <NUM> specific to the department and the rule associated with the single data record cell. For example, if the reviewer single-clicks to select the data record cell <NUM><NUM> (associated with the fourth column 211d of the Contracts departments) the reviewer will be presented with the data view <NUM> populated with data indicative of the rule 204d<NUM> associated with the Contracts department.

In some embodiments, the reviewer can multi-click (for example, double-click) on a plurality of data record cells (horizontal cells) associated with any one rule but spanning across a plurality of departments to select multiple data record cells and to generate the data view <NUM> specific to the rule and the plurality of departments associated with the selected multiple data record cells (horizontal cells). For example, the reviewer may double-click and select the data record cells <NUM><NUM>, <NUM><NUM>, and <NUM><NUM> (associated with the second row 204d<NUM> of the fourth, eleventh and nineteenth columns 211d, 218d, 226d associated with the Contracts, Operations and Services departments) as a result of which the reviewer is presented with the data view <NUM> populated with data indicative of the rule in the second row 204d<NUM> across multiple departments of Contracts, Operations and Services.

Referring now to <FIG>, in embodiments, the reviewer is enabled, through the data view <NUM>, to add a first review note <NUM> that may include a summary of the review report for a department or that may be directed or related to completion/implementation status of multiple rules associated with the department (Contracts department, in this illustration). The reviewer is further enabled to add one or more second review notes <NUM> each of which may be directed or related to a specific rule.

As shown, the data view <NUM> has a first region <NUM> displaying a first notes field <NUM> that is configured as a Word Editor to enable the reviewer to input the first review note <NUM> therein. A field <NUM> displays a date of creation of the review report, the date being automatically populated and associated with the first and second review notes. In embodiments, the date cannot be modified or edited by the reviewer. The data view <NUM> has a second region <NUM> displaying a visual grid <NUM>. The visual grid <NUM> has a first column <NUM> displaying data indicative of a plurality of rules (for example, rules 204d<NUM>, 204d<NUM> and 204d<NUM> associated with the Contracts department), a second column <NUM> displaying the department (Contracts department, in this illustration) to which each of the plurality of rules is related to, a third column <NUM> displaying the name of a department manager (approver and/or implementer) responsible for executing on each of the plurality of rules, a fourth column <NUM> to display the status of approval data, and a fifth column <NUM> displaying a date of review (conducted by the reviewer) of each of the plurality of rules.

In some embodiments, a sixth column <NUM> is configured to display a visual icon corresponding to each of the plurality of rules (in each row). A visual icon when clicked causes a second notes field <NUM> to be generated and displayed for the rule corresponding to the visual icon. The second notes field <NUM> is configured as a Word Editor to enable the reviewer to input the second review note <NUM> for the rule. For example, if the reviewer clicks on the visual icon <NUM> (in the second row <NUM>) the second notes field <NUM> is generated and displayed to enable the reviewer to add the second review note <NUM> related to the rule (of the second row <NUM> and first column <NUM>) titled "Inspection of Research and Development". Once the second review note <NUM> has been input by the reviewer, he may click on a visual button <NUM> to associate the second review note <NUM> with the rule (of the second row <NUM> and first column <NUM>) titled "Inspection of Research and Development" and save in the at least one database <NUM>. Thus, if required, the reviewer can add a review note to each of the plurality of rules.

It should be appreciated that the data view <NUM> allows the reviewer to further drill-down (by clicking) on any of the rules records to access additional data related to each of the rules such as, for example, the rule implementation status.

In accordance with aspects of the present specification and with reference to the GUI 200B of <FIG>, data such as the rules input by the administrator, the regulation corresponding to each input rule and the state (first, second or third) associated with each input rule is organized in a data structure, referred to hereinafter as a library of rules, within the at least one database <NUM>. In some embodiments, the library of rules is accessible to all authorized individuals within the organization regardless of departments, roles or functions. In some embodiments, the library of rules is also accessible to entities external to the organization. For example, various companies across different industries may be granted access (by the administrator) to the library of rules.

Access to the library of rules is advantageous in that there is no need to recreate rules such as, for example, those related to standard guidelines, directives or regulations. Instead rules can be conveniently replicated, imported and associated with a product and/or service contract from the library. Additionally, the use of the library prevents errors such as, but not limited to, duplication of rules as a result of typing errors and/or associating a rule to a wrong regulation.

<FIG> shows an exemplary first GUI 600a displaying a plurality of rules and associated data along with an exemplary second GUI 600b configured to display a library of rules, in accordance with some embodiments of the present specification.

In some embodiments, the GUI 600a displays a visual grid <NUM> that presents a plurality of rules and associated data accessed from the at least one database <NUM>. As shown in the visual grid <NUM>, a first column <NUM> displays first data indicative of the plurality of rules, each of the plurality of rules being presented in a respective row of a plurality of rows <NUM>. A second column <NUM> displays second data indicative of an alternative description of one or more data structures. A third column <NUM> displays third data indicative of a version date corresponding to each of the plurality of rules. A fourth column <NUM> displays fourth data indicative of a regulation associated with each of the plurality of rules. A fifth column <NUM> displays fifth data indicative of a state (first, second or third) associated with each of the plurality of rules. A sixth column <NUM> displays sixth data indicative of whether each of the plurality of rules are applied to other data structures. A seventh column <NUM> displays seventh data indicative of whether each of the plurality of rules has an active or inactive status. That is, whether a rule is still a valid/enforceable one or not. Also, an eighth column <NUM> displays eighth data indicative of at least one action corresponding to each of the plurality of rules.

Data displayed in the visual grid 600a can be downloaded in Excel or PDF formats by actuation icons <NUM>, <NUM> respectively. A visual icon or button <NUM> is provided to invoke a library of rule and enable the user to add or import one or more rules (and associated data) to the visual grid 600a. In some embodiments, the visual icon or button <NUM> when clicked causes the module <NUM> to generate and present the second GUI 600b to the user.

In some embodiments, the second GUI 600b enables a user to access a plurality of pre-stored library of rules and associated data accessed from the at least one database <NUM>. In some embodiments, data from the library of rules may be filtered on the basis of a guideline, directive or regulation using a first field <NUM> and/or a state (first, second or third) using a second field <NUM>. In some embodiments, each of the first and second fields <NUM>, <NUM> is configured as a pre-populated drop-down list. A third field <NUM> enables the user to search for specific rules within the library and is configured as a text box. In some embodiments, the first, second and third fields <NUM>, <NUM> and <NUM> are displayed in a first region <NUM> of the second GUI 600b.

In some embodiments, the second GUI 600b has a second region <NUM> displaying a visual grid <NUM>. The visual grid <NUM> displays data in a plurality of rows and columns. A second column <NUM> displays second data indicative of a plurality of rules, each of the plurality of rules being displayed in a respective row <NUM>. A first column <NUM> displays first data indicative of IDs and version dates associated with each of the plurality of rules. Also, a third column <NUM> displays third data indicative of an action corresponding to each of the plurality of rules. In some embodiments, the third data is configured in the form of a visual icon that could be of different shapes, sizes, colors, textures, orientations, blink rates, imagery (inanimate or animate) and/or other visual traits. In some embodiments, clicking or actuating a visual icon (third data) corresponds to an action of selecting or choosing a rule for import.

In various embodiments, the second and third data are displayed in respective cells of the visual grid <NUM>, wherein the respective cells are defined by intersection of respective columns and rows and are visually aligned, horizontally (in a row), with a first data. For example, as shown in the visual grid <NUM>, for a rule titled "gratuities" (in third row <NUM><NUM>) a cell <NUM><NUM> displays the first data and a cell <NUM><NUM> displays the third data. The cell <NUM><NUM> is defined by an intersection of the first column <NUM> and the third row <NUM><NUM> and is visually aligned, horizontally, with the rule in the third row <NUM><NUM>. Similarly, the cell <NUM><NUM> is defined by an intersection of the third column <NUM> and the third row <NUM><NUM> and is visually aligned, horizontally, with the rule in the third row <NUM><NUM>. Now clicking the visual icon in cell <NUM><NUM> results in the action of selecting the rule and associated data (such as, but not limited to, the ID and version date (first data), a regulation data and a state data associated with the rule). The action of selecting causes a copy of the rule and the associated data to be imported from the library to the first GUI 600a and therefore stored into a data structure, in the at least one database <NUM>, representative of the data view of the first GUI 600a.

In some embodiments, the user can click on the first data to open an information box that displays details or explanation notes related to the second data that is visually aligned with the first data. For example, clicking the cell <NUM><NUM> opens an information box <NUM> that displays details or explanation notes related to the rule titled "gratuities" (in the third row <NUM><NUM>). In some embodiments, the information box <NUM> also displays data <NUM> indicative of a state (first, second or third) associated with the rule.

In embodiments, electronic data structures that contain a plurality of data in at least one category are input into a system having a memory, wherein said memory is then accessed to determine which stakeholders should receive the information and which of the plurality of data can be automatically updated within the electronic data structures. <FIG> is a flowchart of a plurality of exemplary steps for automatically processing an electronic data structure. It should be understood that the steps described herein may be implemented in a system in which a plurality of improved GUIs (Graphical User Interfaces), for distributed rules and workflow management in an organization, are generated and displayed, in accordance with some embodiments of the present specification and as described with respect to <FIG>. In embodiments, the system for automatically processing an electronic data structure includes at least one processor, a first non-transient memory, and a plurality of programmatic instructions stored in the first non-transient memory. In embodiments, the plurality of programmatic instructions are executed by the at least one processor, and cause the server to receive the electronic data structure, wherein the electronic data structure associates a plurality of data with a plurality of different categories. The server may also access the plurality of different categories from a second non-transient memory, wherein the plurality of different categories is stored in the second non-transient memory in association with each of a plurality of stakeholders and wherein each of the plurality of stakeholders is stored in the second non-transient memory in association with one or more electronically addressable locations. In embodiments, the one or more electronically addressable locations comprise an email address, a hardware address, and/or a mobile phone number.

In embodiments, the plurality of programmatic instructions, when executed by the at least one processor, is configured to generate data representative of a graphical user interface wherein the graphical user interface is configured to prompt a user to associate at least one of the plurality of different categories with at least one of the plurality of stakeholders.

In embodiments, the plurality of programmatic instructions, when executed by the at least one processor, is further configured to generate data representative of a graphical user interface wherein the graphical user interface is configured to display, in a first region, data indicative of at least one of the plurality of categories and, in a second region, data indicative of at least one of the first states or the second states.

In embodiments, data indicative of at least one of the plurality of categories comprise a hyperlink, which, when activated causes another graphical user interface to be generated for displaying details related to the at least one of the plurality of categories.

In embodiments, the plurality of programmatic instructions, when executed by the at least one processor, is further configured to send one or more notifications to the at least one of the plurality of stakeholders at the one or more electronically addressable locations after routing and before receiving the input.

Referring back to <FIG>, for automatically processing an electronic data structure, at step <NUM>, an electronic data structure is received in a server, wherein the electronic data structure associates a plurality of data with a plurality of different categories. At step <NUM>, using the server, the plurality of different categories is accessed from a memory. In embodiments, the plurality of different categories is stored in the memory in association with each of a plurality of stakeholders. In embodiments, each of the plurality of stakeholders is stored in the memory in association with one or more electronically addressable locations. In embodiments, the one or more electronically addressable locations comprise an email address, a hardware address, and/or a mobile phone number.

Using the server, it is determined at step <NUM>, for a first subset of the plurality of different categories, whether to automatically update a first set of states associated with the electronic data structure without routing the electronic data structure to at least one of the plurality of stakeholders using the one or more electronically addressable locations. Using the server, it is determined, at step <NUM>, for a second subset of the plurality of different categories, to route the electronic data structure to at least one of the plurality of stakeholders using the one or more electronically addressable locations.

At least a portion of the electronic data structure is routed using the server, at step <NUM>, to at least one of the plurality of stakeholders using the one or more electronically addressable locations. In embodiments, after routing and before receiving input, the server is used to send one or more notifications to the at least one of the plurality of stakeholders at the one or more electronically addressable locations.

At least one of the plurality of stakeholders provides input, which is received, at step <NUM>, by the server. At step <NUM>, a second set of states is updated, using the server, based on the input received from the at least one of the plurality of stakeholders. At step <NUM>, data that is visually representative of each of the first set of states and second set of states is generated using the server.

In embodiments, the visually representative data is received at a client device and is displayed such that each of the first set of states and second set of states is visually associated with the electronic data structure. In embodiments, at least one of the first set of states is indicative of at least one of the first subset of the plurality of categories being approved. In embodiments, at least one of the second set of states is indicative of at least one of the second subset of the plurality of categories not being approved. In embodiments, the at least one of the first set of states indicative of being approved is visually distinct from the at least one of the second set of states not being approved.

In embodiments, the server may be employed to generate data representative of a graphical user interface wherein the graphical user interface is configured to prompt a user to associate at least one of the plurality of different categories with at least one of the plurality of stakeholders. In additional embodiments, the server may be employed to generate data representative of a graphical user interface wherein the graphical user interface is configured to display, in a first region, data indicative of at least one of the plurality of categories and, in a second region, data indicative of at least one of the first states or the second states.

<FIG> is a flowchart of a plurality of exemplary steps of implementing a workflow directed towards ensuring that one or more business processes of an organization are in conformance with one or more of a plurality of rules, in accordance with some embodiments of the present specification. Referring now to <FIG> and <FIG>, at step <NUM>, an administrator uses a browser application or a client-side module on his client device <NUM> to log into the at least server <NUM>. At step <NUM>, successful logging of the administrator causes the rules and workflow management module <NUM> to generate and present one or more GUIs on the administrator's client device in accordance with predefined access privileges and permission rights corresponding to the administrator. The one or more GUIs may be populated with data in accordance with the predefined access privileges and permission rights.

At step <NUM>, the administrator accesses at least a first GUI such as, for example, the GUI 200b of <FIG> to input first data indicative of a rule and additional data. In some embodiments, the additional data is indicative of, for example, department to which the rule pertains to and is assigned, employee designation to which the rule is assigned, employee name to whom the rule is assigned, rule state (first, second or third), regulation to which the rule relates to, user-profile (approver and/or implementer) of the employee to whom the rule is assigned, type and frequency of reminders to be generated for communication to the employee and a frequency at which to automatically enable a triggering of re-certification (of fulfillment) of the rule.

It should be appreciated that apart from the first GUI (example, GUI 200b of <FIG>) the administrator can access a plurality of GUIs to review the first data and the additional data in various ways or views. For example, the administrator may access the GUIs of <FIG>, <FIG>, <FIG>, <FIG>, and <FIG> as and when needed.

In embodiments, the administrator obtains the first data from a competent authority and periodically updates the first data, in the at least one database <NUM>, with respect to the competent authority. It should be appreciated that the competent authority may be internal or external to the organization. For example, a Work Culture and Ethics Committee may be internally formed by a Board of Directors of an organization and formulate a plurality of work, culture and ethics related rules. On the other hand, a Medical Ethics Committee may be an external agency responsible for oversight of medical or human research studies in a country or region and formulate a plurality of rules related to medical or human research.

At step <NUM>, the administrator saves, in the at least one database <NUM>, the first data in association with the additional data.

At step <NUM>, the module <NUM> auto-generates a first reminder or message that is sent to the employee to whom the rule is assigned prompting him to review the assigned rule and establish the organization's position - that is, approve, deny or analyze to decide full, partial or no approval of the rule. In embodiments, the employee may be designated as an approver, implementer or both based on the data indicative of the user-profile of the employee to whom the rule is assigned.

At step <NUM>, consequent to receiving the first reminder or message, the employee to whom the rule is assigned uses a browser application or a client-side module on his client device <NUM> to log into the at least server <NUM>.

At step <NUM>, subsequent to successful logging of the employee, the module <NUM> determines (based on the employee's stored user-profile) if the employee is an approver, implementer or both. If the employee is determined to be an approver or both an approver and an implementer (that is, the employee is associated with the approver user-profile) then, at step 716a, the employee is allowed access to at least a second GUI such as, for example, the GUI 200d of <FIG> to review the assigned rule and approve, deny or analyze to decide full, partial or no approval of the rule. In some embodiments, a state associated with the rule initially depends on the state input by the administrator through the GUI 200b (at step <NUM>). However, in some embodiments, the state may be modified (to another state) by the approver (who may or may not be an implementer as well) during review.

Referring to <FIG>, in some embodiments, the approver is allowed to click on a cell in the second column 208d to open a dialogue box and modify the current state of a rule (in the first column 204d) visually aligned, horizontally, with the cell. For example, the approver may click the cell 205d (in the fourteenth row 206d<NUM>) to modify the third state (indicative of the rule requiring analyses to decide full, partial or no acceptance/implementation) of the fourteenth rule (in the fourteenth row 206d<NUM>) to the first state (indicative of the rule being approved) or second state (indicative of the rule being denied approval). It should be appreciated that, where a given rule is assigned to multiple persons, each of the multiple persons may approve, deny, or otherwise modify a state of the rule independent of each of the other multiple persons. In such a case, a different status icon would be displayed corresponding to the rule and each of the multiple persons.

It should be appreciated that apart from the second GUI (GUI 200d of <FIG>) the approver can access a plurality of GUIs to review the first data and the additional data in various ways or views. For example, the approver may access the GUIs of <FIG>, <FIG>, and <FIG> as and when needed.

However, if the employee is determined to be only an implementer then, at step 716b, the employee is allowed access to third and fourth GUIs such as, for example, the GUIs 400a and 400b of <FIG>, <FIG> to enable the implementer to review and interact with data related to conformance of one or more products and/or services with the rule. As non-limiting examples, the GUIs 400a and 400b of <FIG>, <FIG> enable the implementer (who, in one embodiment, is a Contracts Manager) to review and interact with data related to conformance of one or more products and/or service contracts with the rule.

In some embodiments, the implementer is not allowed access to other GUIs such as, for example, the GUIs of <FIG> and <FIG> that are accessible to approvers and implementers.

Thus, successful logging of the employee, at step <NUM>, causes the rules and workflow management module <NUM> to generate and present one or more GUIs on the employee's client device in accordance with predefined access privileges and permission rights corresponding to the employee's user-profile - that is, approver and/or implementer. The one or more GUIs may be populated with data in accordance with the predefined access privileges and permission rights.

Claim 1:
A method of selectively routing data through an electronic network (<NUM>), comprising:
receiving (<NUM>), in a server (<NUM>), an electronic data structure, wherein the electronic data structure associates a plurality of data with a plurality of different categories;
using the server, accessing (<NUM>) the plurality of different categories from a memory, wherein the plurality of different categories is stored in the memory in association with each of a plurality of stakeholders and wherein each of the plurality of stakeholders is stored in the memory in association with one or more electronically addressable locations;
using the server, determining (<NUM>), for a first subset of the plurality of different categories, to automatically update a first set of states associated with the electronic data structure without routing the electronic data structure to at least one of the plurality of stakeholders using the one or more electronically addressable locations;
using the server, determining (<NUM>), for a second subset of the plurality of different categories, to route the electronic data structure to at least one of the plurality of stakeholders using the one or more electronically addressable locations;
using the server, routing (<NUM>) at least a portion of the electronic data structure to at least one of the plurality of stakeholders using the one or more electronically addressable locations;
using the server, receiving (<NUM>) input from the at least one of the plurality of stakeholders;
using the server, updating (<NUM>) a second set of states based upon the received input;
using the server, generating (<NUM>) data that is visually representative of each of the first set of states and second set of states; and
using the server, generating data representative of a graphical user interface wherein the graphical user interface is configured to display, in a first region, data indicative of at least one of the plurality of categories and, in a second region, data indicative of at least one of the first states or the second states, wherein data indicative of at least one of the plurality of categories comprise a hyperlink, which, when activated, causes another graphical user interface to be generated for displaying details related to the at least one of the plurality of categories.