WO2021044197A1

WO2021044197A1 - Blockchain for workflow

Info

Publication number: WO2021044197A1
Application number: PCT/IB2019/057510
Authority: WO
Inventors: Atsushi Shimamura
Original assignee: Hitachi, Ltd.
Priority date: 2019-09-06
Filing date: 2019-09-06
Publication date: 2021-03-11

Abstract

Workflow is commonly used in various organizations, and sometimes, inter-organizations. To establish a workflow, one administrator defines the workflow definition, and one workflow engine executes the workflow. In a distributed environment (e.g., multiple organizations have same privilege, no one administrator exists), this implementation may not work. Example implementations described herein are directed to methods and systems to define and execute the workflow among a distributed environment, such that the organizations do not need to trust any other organization in the distributed environment.

Description

BLOCKCHAIN FOR WORKFLOW

BACKGROUND

Field

[0001] The present disclosure is generally directed to information technology (IT) workflow systems, and more specifically, to management of IT workflow systems by blockchain.

Related Art

[0002] In related art implementations, there are version control systems through use of blockchain, in which the developers are distributed. In such related art implementations, blockchain and blockchain applications (e.g., software running on a blockchain platform) are used to manage developed source code. Blockchain applications check the codes based on the various rules, such as formatting, naming conventions, function types, and so on.

[0003] Based on such related art implementations, developers can send their updates on source code to the blockchain based version control system. Further, blockchain based version control systems merge the source code to the repository only when the source code meets the rules of the blockchain.

SUMMARY

[0004] Workflow is commonly used in various organizations, and sometimes, inter-organizations. To establish a workflow, one administrator defines the workflow definition, and one workflow engine executes the workflow definition. In a distributed environment (e.g., multiple organizations have same privilege, no one administrator exists), such implementations may not work.

[0005] Example implementations described herein are directed to methods and systems to define the workflow definition and execute the workflow definition on a distributed environment, such that no organization needs to trust any other specific organization in the system. [0006] Example implementations described herein involve a system/method for realizing trustful distributed workflow, and can involve several aspects. An example aspect can include facilitating distributed runnable workflow definition creation, wherein each administrator for the associated organizations has the same privilege. No one administrator can alter the definition without breaking requirements of other administrators.

[0007] In another aspect, the workflow definition creation is run on blockchain to avoid fraud by one organization. Further, the workflow runs on blockchain via a blockchain based workflow engine. The workflow engine executes the workflow definition created from the workflow definition creation. To create a runnable workflow definition, the tool uses requirements on basic workflow definition, and creates a workflow definition, which satisfies all of the requirements sent from multiple organizations. The requirements can include requirements to fields, requirements to steps and requirements to roles.

[0008] Aspects of the present disclosure include a method for implementing a workflow between a plurality of organizations in a blockchain network, the method involving receiving a plurality of workflow definition requirements from the plurality of organizations and providing the plurality of workflow definition requirements to the blockchain network; determining, on the blockchain network, whether a workflow can be generated from the workflow definition requirements received from the plurality of organizations; and for the determining indicating that the workflow can be generated, generating the workflow and executing the workflow on the blockchain network.

[0009] Aspects of the present disclosure include a non-transitory computer readable medium, storing instructions for implementing a workflow between a plurality of organizations in a blockchain network, the instructions involving receiving a plurality of workflow definition requirements from the plurality of organizations and providing the plurality of workflow definition requirements to the blockchain network; determining, on the blockchain network, whether a workflow can be generated from the workflow definition requirements received from the plurality of organizations; and for the determining indicating that the workflow can be generated, generating the workflow and executing the workflow on the blockchain network. [0010] Aspects of the present disclosure include a system for implementing a workflow between a plurality of organizations in a blockchain network, the method involving means for receiving a plurality of workflow definition requirements from the plurality of organizations and providing the plurality of workflow definition requirements to the blockchain network; means for determining, on the blockchain network, whether a workflow can be generated from the workflow definition requirements received from the plurality of organizations; and for the determining indicating that the workflow can be generated, means for generating the workflow and executing the workflow on the blockchain network.

[0011]

BRIEF DESCRIPTION OF DRAWINGS

[0012] FIG. 1 illustrates an example overall structure of the example implementations described herein.

[0013] FIG. 2 illustrates an example structure of a node, in accordance with an example implementation.

[0014] FIG. 3 shows a data structure of block data stored in blockchain storage, in accordance with an example implementation.

[0015] FIG. 4 illustrates the example of a workflow in accordance with an example implementation.

[0016] FIG. 5 illustrates the flowchart of overall workflow lifecycle, in accordance with an example implementation.

[0017] FIG. 6 illustrates the fields definition, in accordance with an example implementation.

[0018] FIG. 7 illustrates the role definition, in accordance with an example implementation.

[0019] FIG. 8 illustrates the sequence definition, in accordance with an example implementation. [0020] FIG. 9 illustrates the flowchart of workflow definition creation, in accordance with an example implementation.

[0021] FIG. 10 illustrates the requirements to fields, in accordance with an example implementation.

[0022] FIG. 11 illustrates requirements to steps, in accordance with an example implementation.

[0023] FIG. 12 illustrates requirements to roles, in accordance with an example implementation.

[0024] FIG. 13 illustrates the details of finding a runnable workflow definition, in accordance with an example implementation.

DETAILED DESCRIPTION

[0025] The following detailed description provides details of the figures and example implementations of the present application. Reference numerals and descriptions of redundant elements between figures are omitted for clarity. Terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term “automatic” may involve fully automatic or semi-automatic implementations involving user or administrator control over certain aspects of the implementation, depending on the desired implementation of one of ordinary skill in the art practicing implementations of the present application. Selection can be conducted by a user through a user interface or other input means, or can be implemented through a desired algorithm. Example implementations as described herein can be utilized either singularly or in combination and the functionality of the example implementations can be implemented through any means according to the desired implementations.

[0026] Workflow is a common business process in enterprise. Usually, administrator of the organization or division designs the workflow definitions (sequence of operations, data fields used in the workflow, users and groups roles, etc.). This administrator usually uses a workflow design tool, which may have a GUI (Graphical User Interface) for workflow definitions. The tool may use BPMN (Business Process Modeling Notation) or BPEL (Business Process Execution Language) to define and store the workflow definition. Then, the defined workflow will run on the workflow engine, which controls the overall status of each workflow, user and group roles, and manage workflow related data.

[0027] This kind of IT workflow system, including the design tool (tool for administrator) and engine, is very common and useful within an organization. In such IT workflow systems, it can be trivial to select the administrator who designs the workflow, and then the organization can control the IT system which executes the workflow design tool and workflow engine.

[0028] However, such a workflow configuration may not be applicable for workflow among multiple organizations or multiple divisions, where there is (1) no trusted administrator, (2) no trusted design tool, and (3) no trusted workflow execution engine.

[0029] Regarding the lack of a trusted administrator, when multiple organizations establish workflow among the organizations, it might be difficult to select one privileged administrator. Related art implementations involve methods for distributed version control system for developing software code. In the related art implementations, the code developer who sends the code last can control the overall software as long as the code complies with the rules set forth. Thus, the related art implementations cannot be applicable to define the workflow among multiple organizations, in particular since organizations cannot trust the administrators of outside organizations.

[0030] Regarding the lack of a trusted design tool, multiple administrators may use the design tool, and the user (e.g., administrator of one organization) must have sufficient confidence to trust the design tool. In particular, the administrator of the design tool (e.g.„ IT administrator of the software, or server which runs the tool) can alter the data on the server (e.g., such as workflow definition) using their access privilege on the server.

[0031] Regarding the lack of a trusted workflow execution engine, multiple companies may share one workflow engine. However, if the companies use one workflow engine, the administrator of the engine may control the workflow and alter the data used by the workflow.

[0032] To clear these problems, the example implementations described herein are directed to designing workflow definition among multiple administrators, in which trustful workflow design tool, and trustful workflow execution engine are required. [0033] FIG. 1 illustrates an example overall structure of the example implementations described herein. Workflow blockchain 110 is a blockchain network involving a plurality of nodes. In the example of FIG. 1, there are three organizations with each organization corresponding to a node, however the present disclosure is not limited thereto and any configuration may be utilized in accordance with the desired implementation. Node A 111, node B 112 and node C 113 are operated by organizations A, B, and C respectively. Admin system A 121, admin system B 122, and admin system C 123 are systems used by the administrator who designed the workflow of the respective organization. User system A 131, user system B 132, and user system C 134 are systems used by the workflow users of the respective organization.

[0034] Each admin system and user system are connected to a node operated by the corresponding organization. For example, as shown in FIG. 1, admin system A 121 and user system A 131 are connected to node A111, which are operated by same company (‘A’). As blockchain network, workflow blockchain 110 executes a transaction (e.g., executes blockchain application), make a consensus on the transaction, and records the data into the blockchain ledger. Blockchain application is software run on blockchain network.

[0035] FIG. 2 illustrates an example structure of a node, in accordance with an example implementation. All nodes in workflow blockchain 110 have a similar structure as shown in FIG. 2. Node has memory 210, local storage 220, communication interface 251, processor 252 and Input/Output (I/O) device 253. Processor 252 loads the program from local storage 220 into memory 210 and executes the program. Communication interface 251 is for example, network interface connecting to Internet. EO device 253 can include, for example, keyboard and display.

[0036] Local storage 220 stores blockchain application 221, consensus program

222, blockchain storage 223, database 224 and operating system 229.

[0037] Blockchain application 221 is a software applications, which runs across the entire, or a portion of blockchain network 110, such that all nodes or some portion of the nodes in the workflow blockchain 110 runs same software with same input. Then, the nodes make a consensus on the output of the blockchain application; the outputs should be identical as all nodes run same software with same input. For example, when half (or more) nodes agree on the transaction (input and output of blockchain application 221), the consensus is made.

[0038] Consensus program 221 is a program to make a consensus among nodes.

By executing consensus program 222, the node exchanges messages with other nodes, and make a consensus on the transaction. Then, the node stores the transaction data into blockchain storage 223 as a blockchain. Blockchain storage 223 is storage to store blockchain (details will be noted later).

[0039] Database 224 is storage to store data used by blockchain application 221.

As blockchain storage 223 stores data in multiple blocks, it is difficult to access the data from an application (e.g., such as blockchain application 221). So, in example blockchain implementations, blockchain application 221 can use KVS (key value store) or other type of data store depending on the desired implementation. This database 224 is not part of the blockchain storage 223, but its contents are protected by the blockchain storage 223. For example, blockchain storage 223 stores all of the change logs of database 224. Thus, by using the data in blockchain storage 223, the data in database 224 can be generated. When blockchain application updates the database 224, correspondent change log data will be stored on blockchain storage 223.

[0040] Operating system 243 is a common program for basic functionalities.

[0041] As described herein, the node is configured to implement a workflow between a plurality of organizations in a blockchain network by facilitating the architecture in FIG. 1. Processor(s) 252 can be configured to receive a plurality of workflow definition requirements from the plurality of organizations and providing the plurality of workflow definition requirements to the blockchain network as illustrated in FIGS. 1-5; determining, on the blockchain network, whether a workflow can be generated from the workflow definition requirements received from the plurality of organizations as illustrated at 622 of FIG. 9; and for the determining indicating that the workflow can be generated, generating the workflow and executing the workflow on the blockchain network as illustrated at 623 and 624 of FIG. 9. The workflow for the blockchain can then be generated from the definitions as defined in FIGS. 6-8 and modifications made thereto.

[0042] For the determining indicating that the workflow cannot be generated, processor(s) 252 can be configured to provide modification directions for the workflow definition requirements corresponding ones of the plurality of organizations as illustrated at 625 of FIG. 9; and for receipt of updated workflow definition requirements from the corresponding ones of the plurality of organizations, determine, on the blockchain network, whether the workflow can be generated from the updated workflow definition requirements as illustrated at 626 and 622 of FIG. 9.

[0043] As illustrated in FIG. 13, processor(s) 252 can be configured to determine, on the blockchain network, whether a workflow can be generated from the workflow definition requirements received from the plurality of organizations by applying the workflow definition requirements to data fields used in the workflow, sequence of operations in the workflow, and roles of one or more of the plurality of organizations of the workflow as illustrated at 701, 704 and 707 of FIG. 13, for the workflow definition requirements being successfully applied to the data fields used in the workflow, the sequence of operations in the workflow, and the roles of one or more of the plurality of organizations of the workflow, determining that the workflow can be generated as illustrated at 710 of FIG. 13; and for the workflow definition requirements not being successfully applied to one or more of the data fields used in the workflow, the sequence of operations in the workflow, and the roles of one or more of the plurality of organizations of the workflow, determining that the workflow cannot be generated as illustrated at 703, 706 and 709 of FIG. 13.

[0044] In example implementations, the plurality of workflow requirements can involve one or more of: requirements to data fields used in the workflow, requirements to a sequence of operations in the workflow, and requirements to roles of one or more of the plurality of organizations of the workflow as illustrated in FIGS. 6-12. In the present disclosure, the terms ’’operations” and “steps” may be utilized interchangeably. For example, the requirements to the sequence of the operations in the workflow can involve one or more requirements following after or before a specified operation in the sequence of operations as illustrated in FIG. 8 at 534 and FIG. 11 at 645. Further, as illustrated in FIG. 11, the requirements to the sequence of operations in the workflow can also involve an addition or a deletion to one or more of the operations in the sequence of operations in the workflow as illustrated in FIG. 11 at 641 and 642.

[0045] FIG. 3 shows a data structure of block data 300 stored in blockchain storage 223, in accordance with an example implementation. In blockchain storage 223, data is stored on several blocks, which are connected mathematically. Block number 301 is the sequential number of blocks. Hash value of previous block 302 is mathematically calculated value from the previous block 302 (e.g., calculated by hash algorithm based on the data of previous block 302). Number of transactions 303 is number of data in transactions data 310. To increase the throughput of recording data, multiple transactions can be recorded on one block. Timestamp 304 is date and time of the block was created.

[0046] Transactions data 310 includes one or more transaction data entries 320.

Transaction data entries 320 may involve various data of transactions executed on the blockchain network 110. In the example of FIG. 3, transaction data entries 320 includes input data 321 and output data 322. Input data 321 is input used to execute blockchain application 221. Output data 322 is output of blockchain application 221. Nodes in blockchain network 110 make a consensus based on the input and output of blockchain application 221, and records them into blockchain storage 223 (as one of transaction data 310). By recording such data, the history of executing blockchain application 221 will not be altered without breaking the connection between blocks, as the hash value of previous block 302 is used to check the consistency of the blocks.

[0047] FIG. 4 illustrates the example of a workflow in accordance with an example implementation. Specifically, FIG. 4 illustrates an example workflow for ordering an item.

[0048] In workflow shown in this FIG. 4, there are three organizations (buyer, seller and logistics). At 401, the buyer creates a new order, then seller answers the price based on the order at 402, and logistics answers with the freight cost at 403. After seller and logistics provide their corresponding answer, buyer approves (or declines) the transaction at 404. Once the transaction is approved, information is sent to seller and logistics in the form of instructions (e.g., instructions to sell 405, instructions to deliver 406).

[0049] FIG. 5 illustrates the flowchart of overall workflow lifecycle, in accordance with an example implementation. In FIG. 5, admin system A 121, node A 111 and user system A 131 are operated by a buyer organization. Admin system B 122, node B 112 and user system B 132 are operated by a seller organization. Admin system C 123, node C 113 and user system C 133 are operated by a logistics organization. [0050] At first, the administrator for the buyer (in this example, the initiator who started the process is the buyer in FIG. 4) selects one basic workflow definition and inputs it to admin system A 121. Then, admin system A 121 sends the selection to node A 111 (step 411). The basic workflow definition is template of workflow definition. Multiple basic workflow definitions are stored on nodes in workflow blockchain 110 (stored each node’s blockchain storage 223 (and database 224)). The data structure of basic workflow definition is shown later. For example, at 411, the initiator selects the basic workflow definition (e.g., workflow definition of ordering item, shown in FIG. 4). Blockchain application 221 on node A 111 and other nodes record the selection on blockchain storage 223.

[0051] At 416, all nodes in workflow blockchain 110 will be controlled by blockchain application 221. By using consensus program 222, the transaction data of blockchain application 221 is shared among nodes and each node stores the data on blockchain storage 223 and database 224. Hereinafter, behavior of workflow blockchain 110 and nodes are these processes.

[0052] Next, the administrator for the buyer inputs field values, which are to be set at initialization phase, into admin system A 121 at 412. In the example of FIG. 4, the administrator for the buyer selects the other organizations representing the seller and logistics, and sets their identification information and contact information. Admin system A 121 sends the data to node A 111. At 417, node A 111 receives the data and workflow blockchain 110 records the data.

[0053] Once the workflow blockchain 110 receives the selection of the basic workflow definition and field values for setup, the nodes on workflow blockchain 110 creates the role information at 418. The details of role information are provided further below.

[0054] Next, the admin systems of related organizations and workflow blockchain

110 create the workflow definition at 413 and 419. Details of the workflow definition are provided further below.

[0055] In this FIG. 5, steps of workflow blockchain 110 (step 416, 417, 418, 419) are blockchain application 221. By using blockchain application 221 for these steps, the process of creating workflow definition cannot be altered by one of IT administrator of organization. It means, the distributed workflow definition creation process can be trustful for every administrators.

[0056] After workflow definition is created, the workflow definition is executed by workflow engine (implemented as blockchain application 221) at 420. Based on the created workflow, users use their user systems to operate the workflow at 415. For example, user of buyer uses user system A 131, and input order details. Then user of seller uses user system B 132, and input price, delivery date, etc. User of logistics uses user system C 133, and input freight costs, etc. Workflow engine (implemented as blockchain application 221) executes the workflow definition, and change the state of the workflow based on these inputs from use systems.

[0057] By running the workflow engine as a blockchain application, the engine itself is shared among all of workflow user organization. No single entity (e.g., IT administrator of one organization) can alter the program or data of the workflow engine. Thus, all of the organizations can trust the workflow engine, and can trust that the workflow engine executes the expected workflow definition.

[0058] FIG. 6 illustrates the fields definition, in accordance with an example implementation. Fields definition is one part of the basic workflow definition. It is a table to define the data fields used in workflow. This table has three columns; field 511, type

512 and value 513.

[0059] Field 511 indicates the name of the data field. For example, “Buyer” is the data field to manage the name (or other identifier) of the buyer organization in the workflow. Type 512 involves either “Setup” or “Runtime”. “Setup” means that the value

513 should be defined at first (at 412 and 417). In this example of FIG. 6, type 512 of “Buyer”, “Seller” and “Logistics” are set as “Setup”. Thus, the value 513 of these fields is set at 412 and 417. Other values 513 (e.g., where type 512 is set to “Runtime”) will be set on workflow execution phase (at 415 and 420). Value 513 is the concrete value of the field. At first, value 513 is blank. Then some values (e.g., where type 512 is “Setup”) are set at 417, and other values might be set during the workflow execution phase.

[0060] FIG. 7 illustrates the role definition, in accordance with an example implementation. The role is a user or organization type in the workflow. The role definition is one part of the basic workflow definition, and involves three columns (role 521, identification 522 and contact information 523).

[0061] Role 521 defines the name of the role. Identification 522 is the data to identify the organization which act as the role 521. For example, identification 522 is the name of the organization, or name in digital certificate (e.g., common name, defined in standard of digital certificate). Contact information 523 is information to reach the organization. This is used by workflow engine to notify that the organization have to do something (e.g., request for approval).

[0062] At first, as a basic workflow definition, identification 522 and contact information 523 are blank. At 418 from FIG. 5, workflow blockchain 110 sets the identification 522 and contact information 523. In this process, identification 522 is copied from fields for setup as set at 417. Further, contact information 523 is set based on the identification 522. Preliminarily, the nodes of workflow blockchain 110 store the set of identification and contact information of all possible user companies.

[0063] FIG. 8 illustrates the sequence definition, in accordance with an example implementation. The sequence definition is one part of the basic workflow definition. It has four columns (Step 531, role 532, operation 533 and next step 534). This sequence definition defines the steps of workflow and actions in each step, sequence of steps, and so on. Step 531 is name of the step. In the example of FIG. 8, there are six steps, and they correspond to the example in FIG. 4. Role 532 is the user of the step. For example, step “CreateNewOrder” has role “Buyer”, so the buyer which is identified by role information (using identification 522) will be the user of the step. Operation 533 is the user operation (input, approve, or see) on that step.

[0064] ‘input’ indicates that the user inputs the value of the field in that step

‘approve’ means that the user sees the value already set on the field, and the user inputs whether the user agrees (approves) on the value or not (declines) ‘see’ indicates that the user can see the value of the field.

[0065] For example, in FIG. 8, operation 533 of first record is ‘input

“Specification”’. So, the user in buyer organization will input the data field named as specification (of the order) into the user system (such as user system A 131), and user system A sends it to node A 111. Node A 111 initiate the blockchain application 221, and the blockchain application set the value 513 of ‘Specification’.

[0066] Next step 534 is the step which will be executed (by workflow engine) after current step. In the example, next step 534 of first record is ‘AnswerPrice’. So, after the execution of step ‘CreateNewOrder’, workflow engine executes ‘AnswerPrice’. In some steps, there might be multiple next steps based on the condition of execution phase. For example, step ‘AnswerPrice’ has 2 next steps, which depends on whether user (in this example, “Seller”) approves or declines.

[0067] FIG. 9 illustrates the flowchart of workflow definition creation, in accordance with an example implementation. Specifically, FIG. 9 illustrates the details of process 419 in FIG. 5. In FIG. 9, flowchart 610 is the flowchart for admin system (admin system A 121, etc.). Flowchart 620 is the flowchart for workflow blockchain 110 (flowchart of blockchain application 221 executed on nodes, such as node A 111, etc.).

[0068] At 611 for the workflow definition creation, admin systems send requirements of each organization. This process is conducted by multiple admin systems. Requirements include the requirements of each organization to modify the basic workflow definition. Such requirements can include requirements to fields, requirements to steps and requirements to roles, further details of which are described later. Each administrator of the organization inputs the organization requirements into the admin system, and the admin system may also have a graphical user interface (GUI) to facilitate the display and input of basic workflow definition and input requirements.

[0069] Next at 621, workflow blockchain 110 receives the requirements from admin systems. These requirements are stored on the blockchain storage 223 and database 224 of each node, and the nodes make a consensus on the data. By using these requirements and the basic workflow definition, workflow blockchain 110 can find a runnable workflow definition at 622, details of which are provided below. At 622, the workflow blockchain 110 may fail to find the runnable workflow definition, because some of the requirements may conflict each other. Thus, at 623, the workflow blockchain 110 checks the result, and if it is successful to find the runnable workflow definition (yes), the workflow blockchain 110 ends the workflow definition creation process at 624. [0070] If workflow blockchain 110 fails to find runnable workflow definition (no), the workflow blockchain 110 sends modification directions for the related organizations to admin systems of the related organizations at 625. Modification direction is information which indicates (1) which requirements are to be modified to succeed to create a runnable workflow definition, and (2) the direction regarding how to modify the existing requirements.

[0071] Admin system, which received the modification direction, will output the contents (e.g., displays the contents for administrator), and the administrator will input new requirements at 612 to update the requirement stored in workflow blockchain 110. Workflow blockchain 110 receives the updated requirements at 626, and proceeds to 622 to find the runnable workflow definition based on the updated requirements.

[0072] FIG. 10 illustrates the requirements to fields, in accordance with an example implementation. The requirements to fields are sent in the process of 611 and 612. Requirements to fields involves a table with two columns (action 621 and field 622), and each record defines data field which are to be added to or deleted from basic fields definition (shown in FIG. 6). Action 621 is either ‘add’ or ‘delete’. If action 621 is ‘add’, a new field having the name indicated in field 622 is added to fields definition. If action 621 is ‘delete’, the existing field (where its name is same as field 622) is deleted from the fields definition. In the example of FIG. 10, two fields are added, and one field is deleted.

[0073] FIG. 11 illustrates requirements to steps, in accordance with an example implementation. The requirements to steps are provided in the process at 611 and 612.

[0074] Requirements to steps involve a table with five columns (action 641, step

642, role 643, operation 644 and place 645). Each record defines step which are to be inserted to or deleted from sequence definition (shown in FIG. 8). Action 641 is either ‘add’ or ‘delete’. If action 641 is ‘add’, a new step with the name in step 642 is added to the sequence definition. If action 641 is ‘delete’, the existing step (having the same name as step 642) is deleted from the sequence definition. Step 642 is the name of the step, which will be added or deleted. Role 643 is user of the step (same as role 532). Operation 644 is the user operation (same as operation 533). Place 645 indicates where the step is inserted in the current sequence definition. For example, this place 645 can indicate the place by one or more conditions. In the FIG. 11, place 645 of first record (step 642 is ‘ConfirmDeliveryDate’) has two conditions. First condition (‘after-input’: “DeliveryDate”) indicates that the step should be inserted after the field with name “DeliveryDate” is set. In FIG. 8 (sequence definition), ‘DeliveryDate’ is set on step ‘ AnswerPrice’, so this new step ‘ConfirmDeliveryDate’ should be inserted after this step. Next condition (‘before-input: “FreightCosf”) indicates that the step should be inserted before the field with name “FreightCost” is set.

[0075] FIG. 12 illustrates requirements to roles, in accordance with an example implementation. The requirements to roles is provided in the process at 611 and 612. Requirements to roles involves a table with three columns (role 661, identification 662 and contact information 663). Each field corresponds to role definition shown in FIG. 7.

[0076] FIG. 13 illustrates the details of finding runnable workflow definition, in accordance with an example implementation. Specifically, FIG. 13 illustrates the details for the flow to facilitate the process at 622. As illustrated in FIG. 9, this flow diagram shows the process of workflow blockchain 110 and its nodes. Input and output of blockchain application 221 on all nodes are checked among nodes using consensus program 222, and stored on blockchain storage 223 and database 224. In this flow diagram, workflow blockchain 110 finds a runnable workflow definition, or, when the workflow blockchain 1110 fails to find a runnable definition, workflow blockchain 110 outputs modification direction.

[0077] At first, workflow blockchain 110 applies requirements to fields at 701. In this process, workflow blockchain 110 merges the requirements to fields (sent from multiple organizations) into fields definition. To merge the fields, as shown in FIG. 10, fields are added to or deleted from fields definition. In the example of FIG. 10 (requirements to fields of ordering item workflow), the requirements will change how the buyer describe the order, from ‘specification’ to number and color.

[0078] Workflow blockchain 110 checks whether the application of fields is succeeded or not at 702. For example, if one organization sends a request to delete a field, but another organization does not send the request to delete the field (e.g., the organization sends a request for input, approve, or see for the field), it fails to find the runnable workflow definition. In such an example (no), then the process proceeds to 703 wherein the workflow blockchain 110 adds new record of modification direction (to be sent to the admin system of the organization that sent the requirements to delete the field) that the deletion caused the failure. [0079] Next, workflow blockchain 110 applies requirements to steps at 704. In this step, workflow blockchain 110 merges the requirements to steps (sent from multiple organizations) into sequence definition. To merge the steps, as shown in FIG. 11, steps are inserted or deleted from the sequence definition. To insert the step, workflow blockchain 110 checks the place 645 to where it should be inserted. In the example of FIG. 11, the requirements will add new step for buyer to check (and approve) the ‘DeliveryDate’, before logistics input freight cost. And, the requirements will replace the step of seller (‘AnswerPrice’) into two steps (‘ AnswerPrice_factory’ and ‘AnswerPrice_sales’).

[0080] At 705, the workflow blockchain 110 checks whether the application of steps has succeeded. For example, organization may send the requirement to insert the step, in which operation 644 indicates the step input values into some fields. But, the fields might be approved by other organization before the inserted step. In this case, it causes the field value alternation after approval, and it is not appropriate.

[0081] In other case, an organization may send the requirement to delete the step, and in the step to be deleted, operation 644 indicates that the step inputs values into some fields. However, the fields might be approved before, or seen by another organization later. In this case, it causes the deletion of approved field value, or lack of field values. In these cases (no), at 706, workflow blockchain 110 adds a new record of modification direction (to be sent to the sender of the requirement to steps) that the addition or deletion caused the failure to create runnable workflow definition.

[0082] Next, at 707, workflow blockchain 110 applies requirements to roles. In this step, workflow blockchain 110 merges the requirements to roles (sent from multiple organizations) into role information. To merge the roles, requirements to roles are added into role information shown in FIG. 7. In the example of FIG. 12, the requirements will add two new roles. These two roles are used in requirements to steps shown in FIG. 11. Based the requirements to steps in FIG. 11 (delete one step, and add steps, where role 643 is ‘Seller factory’ and role 643 is ‘Seller sales’)), and based on the requirements to roles in FIG. 12 (add those two roles), workflow blockchain 110 will replace the step of seller into two steps, and define the roles of the users.

[0083] At 708, the Workflow blockchain 110 checks whether the application of roles has succeeded or not. For example, in FIG. 11, two new steps (step 642 are ‘ AnswerPrice factory’ and ‘AnswerPrice sales’) use new roles added in FIG. 12 (role 661 are ‘Seller factory’ and ‘Seller sales’). In requirements to roles (FIG. 12), identification 662 of two new roles indicates that these are a division or subsidiary of original ‘Seller’ (in FIG. 12, these two roles have same company name in identification 662, and the same domain name in contact information 663). Thus, the addition of these two roles replaces ‘Seller’ to its two divisions. And, the combination of operation 644 of two new steps (‘AnswerPrice factory’ and ‘AnswerPrice sales’) are the same as operation 533 (where step 531 is ‘AnswerPrice’). So, the additions of these two roles do not change the overall role of the organization (‘Seller’). By checking these steps and roles data, the example in FIG. 11 and FIG. 12 causes no failure.

[0084] In another example, if the requirements to roles (and requirements to related steps) change the overall role of the organization, it can be judged as a failure. In this failure case example (no), workflow blockchain 110 adds new record of modification direction (to be sent to the sender of the requirement to roles) that the addition caused the failure to create runnable workflow definition at 709. At 710, when workflow blockchain 110 succeeded in applying requirements to roles, workflow blockchain 110 ends the finding runnable workflow definition procedure with success.

[0085] To avoid an infinite loop in FIG. 9, workflow blockchain 110 creates the modification direction in FIG. 13, and sends the modification direction to administrator system at 625, with an expectation that the administrator updates the requirements properly. It means, in the process at 622 for the next loop (the loop of 622 to 626), workflow blockchain 110 can find a runnable workflow definition.

[0086] In some cases, the process at 622 (in the second loop, or subsequent loops) cannot find a runnable workflow definition. For example, this case occurs when organizations may be able to accept the change in workflow definition, but the organization did not send the change as requirements. For example, the organization may not need to approve the field X, however, the organization did not send a requirement to change the step to exclude the operation of approval the value of field X. To avoid an infinite loop caused in these situations, workflow blockchain 110 may make more modification directions. The modification direction can include the suggestion to delete the operation in specific steps, and so on.

[0087] Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations within a computer. These algorithmic descriptions and symbolic representations are the means used by those skilled in the data processing arts to convey the essence of their innovations to others skilled in the art. An algorithm is a series of defined steps leading to a desired end state or result. In example implementations, the steps carried out require physical manipulations of tangible quantities for achieving a tangible result.

[0088] Unless specifically stated otherwise, as apparent from the discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing,” “computing,” “calculating,” “determining,” “displaying,” or the like, can include the actions and processes of a computer system or other information processing device that manipulates and transforms data represented as physical (electronic) quantities within the computer system’s registers and memories into other data similarly represented as physical quantities within the computer system’s memories or registers or other information storage, transmission or display devices.

[0089] Example implementations may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may include one or more general-purpose computers selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored in a computer readable medium, such as a computer-readable storage medium or a computer-readable signal medium. A computer-readable storage medium may involve tangible mediums such as, but not limited to optical disks, magnetic disks, read-only memories, random access memories, solid state devices and drives, or any other types of tangible or non-transitory media suitable for storing electronic information. A computer readable signal medium may include mediums such as carrier waves. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Computer programs can involve pure software implementations that involve instructions that perform the operations of the desired implementation.

[0090] Various general-purpose systems may be used with programs and modules in accordance with the examples herein, or it may prove convenient to construct a more specialized apparatus to perform desired method steps. In addition, the example implementations are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the example implementations as described herein. The instructions of the programming language(s) may be executed by one or more processing devices, e.g., central processing units (CPUs), processors, or controllers.

[0091] As is known in the art, the operations described above can be performed by hardware, software, or some combination of software and hardware. Various aspects of the example implementations may be implemented using circuits and logic devices (hardware), while other aspects may be implemented using instructions stored on a machine-readable medium (software), which if executed by a processor, would cause the processor to perform a method to carry out implementations of the present application. Further, some example implementations of the present application may be performed solely in hardware, whereas other example implementations may be performed solely in software. Moreover, the various functions described can be performed in a single unit, or can be spread across a number of components in any number of ways. When performed by software, the methods may be executed by a processor, such as a general purpose computer, based on instructions stored on a computer-readable medium. If desired, the instructions can be stored on the medium in a compressed and/or encrypted format.

[0092] Moreover, other implementations of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the teachings of the present application. Various aspects and/or components of the described example implementations may be used singly or in any combination. It is intended that the specification and example implementations be considered as examples only, with the true scope and spirit of the present application being indicated by the following claims.

Claims

CLAIMS What is claimed is:

1. A method for implementing a workflow between a plurality of organizations in a blockchain network, the method comprising: receiving a plurality of workflow definition requirements from the plurality of organizations and providing the plurality of workflow definition requirements to the blockchain network; determining, on the blockchain network, whether a workflow can be generated from the workflow definition requirements received from the plurality of organizations; and for the determining indicating that the workflow can be generated, generating the workflow and executing the workflow on the blockchain network.

2. The method of claim 1, wherein for the determining indicating that the workflow cannot be generated: providing modification directions for the workflow definition requirements corresponding ones of the plurality of organizations; for receiving updated workflow definition requirements from the corresponding ones of the plurality of organizations, determining, on the blockchain network, whether the workflow can be generated from the updated workflow definition requirements.

3. The method of claim 1, wherein the determining, on the blockchain network, whether a workflow can be generated from the workflow definition requirements received from the plurality of organizations comprises: applying the workflow definition requirements to data fields used in the workflow, sequence of operations in the workflow, and roles of one or more of the plurality of organizations of the workflow, for the workflow definition requirements being successfully applied to the data fields used in the workflow, the sequence of operations in the workflow, and the roles of one or more of the plurality of organizations of the workflow, determining that the workflow can be generated; and for the workflow definition requirements not being successfully applied to one or more of the data fields used in the workflow, the sequence of operations in the workflow, and the roles of one or more of the plurality of organizations of the workflow, determining that the workflow cannot be generated.

4. The method of claim 1, wherein the plurality of workflow requirements comprises one or more of: requirements to data fields used in the workflow, requirements to a sequence of operations in the workflow, and requirements to roles of one or more of the plurality of organizations of the workflow.

5. The method of claim 4, wherein the requirements to the sequence of the operations in the workflow comprises one or more requirements following after or before a specified operation in the sequence of operations.

6. The method of claim 4, wherein the requirements to the sequence of operations in the workflow comprises an addition or a deletion to one or more of the operations in the sequence of operations in the workflow.

7. A non-transitory computer readable medium, storing instructions for implementing a workflow between a plurality of organizations in a blockchain network, the instructions comprising: receiving a plurality of workflow definition requirements from the plurality of organizations and providing the plurality of workflow definition requirements to the blockchain network; determining, on the blockchain network, whether a workflow can be generated from the workflow definition requirements received from the plurality of organizations; and for the determining indicating that the workflow can be generated, generating the workflow and executing the workflow on the blockchain network.

8. The non-transitory computer readable medium of claim 7, wherein for the determining indicating that the workflow cannot be generated: providing modification directions for the workflow definition requirements corresponding ones of the plurality of organizations; for receiving updated workflow definition requirements from the corresponding ones of the plurality of organizations, determining, on the blockchain network, whether the workflow can be generated from the updated workflow definition requirements.

9. The non-transitory computer readable medium of claim 7, wherein the determining, on the blockchain network, whether a workflow can be generated from the workflow definition requirements received from the plurality of organizations comprises: applying the workflow definition requirements to data fields used in the workflow, sequence of operations in the workflow, and roles of one or more of the plurality of organizations of the workflow, for the workflow definition requirements being successfully applied to the data fields used in the workflow, the sequence of operations in the workflow, and the roles of one or more of the plurality of organizations of the workflow, determining that the workflow can be generated; and for the workflow definition requirements not being successfully applied to one or more of the data fields used in the workflow, the sequence of operations in the workflow, and the roles of one or more of the plurality of organizations of the workflow, determining that the workflow cannot be generated.

10. The non-transitory computer readable medium of claim 7, wherein the plurality of workflow requirements comprises one or more of: requirements to data fields used in the workflow, requirements to a sequence of operations in the workflow, and requirements to roles of one or more of the plurality of organizations of the workflow.

11. The non-transitory computer readable medium of claim 10, wherein the requirements to the sequence of the operations in the workflow comprises one or more requirements following after or before a specified operation in the sequence of operations.

12. The non-transitory computer readable medium of claim 10, wherein the requirements to the sequence of operations in the workflow comprises an addition or a deletion to one or more of the operations in the sequence of operations in the workflow.

13. A system, comprising: a plurality of nodes implementing a workflow between a plurality of organizations in a blockchain network, each of the plurality of nodes comprising: a processor, configured to: receive a plurality of workflow definition requirements from the plurality of organizations and providing the plurality of workflow definition requirements to the blockchain network; determine, on the blockchain network, whether a workflow can be generated from the workflow definition requirements received from the plurality of organizations; and for the determination indicating that the workflow can be generated, generate the workflow and execute the workflow on the blockchain network.