Distributed document handling system

Distributed file processing system

<p>110. . . network</p><p>101. . . Image imaging system</p><p>102-109. . . Surrounding</p><p>301. . . Interconnect the periphery</p><p>302. . . System</p><p>303. . . application</p><p>304. . . Java virtual machine</p><p>305. . . Internet connection</p><p>306. . . Intermediate level</p>

The present invention will be explained in detail with reference to the accompanying drawings, in which

Figure 1 shows a distributed system.

Figure 2 is an example of an application service path.

Figure 3 shows the overall architecture of the interconnection surroundings.

Figure 4 is an example of a workstation that provides service management components.

Figure 5 shows the record of the application service.

Figure 6 shows the operation screen of the work proposal processor.

Figure 7 is the flow chart of the work proposal processor.

Figure 8 is a flow chart of the getPath() method.

Figure 9 is a directed graph of the service created during the execution of the getPath() method in this example.

Field of invention

The present invention relates to a distributed document processing system for completing tasks, in which tasks are completed by services distributed on a network, and a task generates a product, which includes: a service pool, in which The service is distributed on a plurality of interconnected processing devices; the device used to input a job specification, which includes the product specification specifying the product to be delivered by the job; and the device used to determine a service path, the service is from Selected from the service pool, it is appropriate to complete the work according to the product specifications.

The term "service path" is used to indicate a set of services involved in the realization of the requested work, and it is not necessarily a set of services that are executed in sequence, but it can cover services that must be executed in parallel.

Background of the invention

With the advent of digital technology, digital photocopiers have become possible. Basically, a digital photocopier includes a scanner for converting document images into electronic images, and a printer for converting electronic images into document images. Between the scanner and the printer, the image is obtained as an electronic digital image. It is these features that provide the capabilities of a digital photocopier with rich features that could not be realized before. Due to the relationship of digital technology, the photocopier has a variety of features that are now possible, such as queueing of work, electronic radio-oriented search, image enhancement technology by performing digital signal processing on electronic images, image editing, and patterning. Identification processing, etc.

Furthermore, these devices can communicate with electronic images, so that a photocopier can be used as a printer to print images received from a host computer and can be used as a fax device To exchange images with other fax machines.

Recently, it has become a well-known technology to exchange print job images from one copying device with another copying device by using communication equipment. The purpose is to process images on other devices, where the processed images are It is sent back to the original copying device and printed out.

These devices are described in Sharp's European Patent No. 0797344. The case describes a distributed file processing system, which includes a plurality of image imaging devices, which can be effectively connected so that they can communicate with each other. Each image imaging device includes a plurality of services that perform image processing functions. What Sharp disclosed is a system in which the device can exchange image information with each other through a communication device. As shown in the above system, tasks in a dynamic distributed environment can be completed by linking services to complete subtasks. However, in such an environment, the more services available, the more possible combinations of services. Furthermore, as the number of available services increases, it can be expected that the number of service combinations that perform a desired task will increase equally. In this case, the system will become unmanageable according to one of the conventional technologies. Furthermore, depending on the circumstances or restrictions imposed by the requester, not all such combinations are desirable. Conventional technology does not deal with these problems.

Summary of the invention

The purpose of the present invention is to avoid the above-mentioned shortcomings and provide a distributed information processing system that efficiently and effectively supports the connection of services and generates a service combination that can meet most of the needs of a user. To achieve this goal, the distributed information processing system described above is improved so that the work specifications also include specifications for specifying environmental restrictions, without affecting the product, and the device used to determine the service path will change the work environment Restrictions are taken into consideration. This will remove the shortcomings that the number of service combinations becomes too high to deal with. When choosing a path, the system according to the present invention can also take into account restrictions such as price, reliability and secrecy. According to the measures of the present invention, it allows the user to apply more restrictions, and the restrictions that are not reflected in the final product delivered by the work, so that the number of solutions provided by the system can follow the needs of the user And increase.

In a further embodiment, an environmental limit is defined as a limit within a sorted range, and the system also includes a sorted range for arranging the sorted ranges according to the environmental constraints, and arranging suitable ones to complete the work The path device and the user interface device are used for the user to select a desired work specification based on the arranged path from a list of arranged work specifications. An environmental restriction can be expressed as a range of values in a certain field, for example, the price must be lower than a certain amount expressed in a certain currency. However, this will allow the creation of multiple paths that can achieve a limit that varies with the value found in a certain environmental limit. In this way, optimization is possible for a certain limit.

In a further embodiment, the system includes a user interface device for the user to select the environmental constraints to be used in the path arrangement. In most of the time, multiple paths suitable for completing the work will be transmitted by the system. These paths will be different in the range of conditions that can be achieved. According to this feature of the present invention, it will provide users with equipment to easily grasp the path that best suits their needs.

In a still further embodiment, the environmental limit is the total price of a work to be completed, and the system includes a device for calculating the total price from the price attributes of services included in a predetermined path. In this way, a user can easily find the cheapest way to accomplish the task.

Schematic description

The present invention will be explained in detail with reference to the accompanying drawings, in which

Figure 1 shows a distributed system.

Figure 2 is an example of an application service path.

Figure 3 shows the overall architecture of the interconnection surroundings.

Figure 4 is an example of a workstation that provides service management components.

Figure 5 shows the record of the application service.

Figure 6 shows the operation screen of the work proposal processor.

Figure 7 is the flow chart of the work proposal processor.

Figure 8 is a flow chart of the getPath() method.

Figure 9 is a directed graph of the service created during the execution of the getPath() method in this example.

Symbol description of main components

110. . . network

101. . . Image imaging system

102-109. . . Surrounding

301. . . Interconnect the periphery

302. . . System

303. . . application

304. . . Java virtual machine

305. . . Internet connection

306. . . Intermediate level

Description of the preferred embodiment

Fig. 1 illustrates an embodiment of a distributed file processing system according to the present invention. The image imaging system 101 includes many processing devices or peripherals 102-109, which are connected to each other through a network 110 and therefore can communicate with each other. Especially for the sake of example, the peripheral 109 is a small-size photocopier/printer, the peripheral 108 is a scanner, the peripheral 104 is a large-volume printer, the peripheral 107 is a file server, and the peripheral 105 It is a general server, the peripherals 102, 103, 104, and 106 are workstations, and the network 110 is a local area network. The network 110 may also be the Internet.

The distributed document processing system according to the present invention completes the work on documents. Documents can be described or characterized in various ways. For the purpose of explaining the present invention, a file will form its characteristics depending on the actual characteristics possessed by a file at a certain moment. Such characteristics determine the state of a file at that moment. Such a state corresponds to a special representation of the file at a certain moment. In a first state, the document can be expressed as a special file encoded in ascii. In the next state, the document can be expressed as a document printed on both sides of A4 paper and bound. A job will now be represented as the conversion of a file with an initial state si to a file with a target state st.

According to the present invention, a job is completed through a service distributed on the Internet. These services are available on various peripheral devices on the Silk Road and perform special functions on files. Examples of these functions are image processing, printing, scanning, encryption, and conversion from a page description language to another page description language. These types of services will be further referred to as application services. When requested to process a certain file, each application service will cause changes to the state of the file. Multiple typical application services will be involved in the completion of a job. When processing a document, the effectiveness of each of these application services will be described with reference to changes in the state of the document. Starting from an initial state si, the application services selected according to the present invention will process the files sequentially and/or in parallel, whereby after each processing, the file will change its state until the target state st is reached. The application service program will be involved in a path in a directed graph according to which time in a work processing stage it determines to be the next application service program.

Figure 2 shows an example of such an application service path. A node (201, 202, 203) in the path represents a special state s where a file is located, and an edge (204) in the directed graph represents an application service that brings the file from an input state to an output state. In the service path shown, the file system gradually transitions from its initial state si (201) through a plurality of intermediate states (203) to the target state st (202), in which each step is completed through an application service. In the manual, a state will be presented as a list of parameter values clearly typed by the typewriter.

Computing environment

Figure 3 illustrates the overall structure of an interconnection perimeter 301. Each perimeter has its own operating system 302. Such an operating system performs basic tasks and defines the environment in which applications are executed. Each peripheral has a plurality of application programs 303 for completing special tasks. The surroundings are connected to each other by a network connection 305, and thus a networked system is formed. Through the network connection, it is possible for applications on different peripherals to interact with each other.

In a specific implementation, some application programs are programmed into the Java language, and a Java virtual machine is required to enable it to be executed on the periphery. The Java virtual machine is provided as a layer 304 on the special operating system. Therefore, all these applications can be executed on all peripherals regardless of the differences in the operating systems below. In order to allow the entire set of interconnected different peripherals, from the perspective of the application, it can be represented as a single virtual machine, and an intermediate layer is provided. The first intermediate level is well known for this art, such as Sun Microsystems' JINI. However, any other environment that provides applications running on various different computers and devices for interacting with each other can also be used in the same way.

According to the present invention, application services that perform special functions on files are available on various perimeters of the network. All application services are distributed together on various peripherals in the system to form a service pool. In order to achieve the purpose of managing these application services, the intermediate layer is extended in a service management system.

The service management system will be further explained with reference to Figure 4. FIG. 4 depicts an embodiment of a workstation, which provides a service management system 402 as a part of the intermediate layer 403, a plurality of application services 404 and local applications 405 and 406. The service management system includes a plurality of service management elements. The basic service management component system is available on every node at any time. Other service management components will be available locally on demand. The service management system will be cautious about application services that can be processed locally and remotely. The service management element can only be handled by the local application service. If necessary, a proxy server can be used for local access. The plurality of service management components include a login 406, a path composition module 407, a transaction manager 408, and a mobility manager 409.

To illustrate the system according to the present invention, an object-oriented model will be used. This will mean that the present invention will be properly explained with reference to the grades and the objects exemplified by these grades. An object can be imagined as a data container, and this data can only be accessed by methods provided by the object. A persistent object refers to an object that is automatically stored and restored when leaving and starting an application. Examples of objects from a level will be indicated by the keyword "new". Background information about the Java language and object-oriented programs can be found in these publications "The Java Envifonment, "AWhite Papef", written by J. Gosling and H. McGilton, and "TheJava Platform", written by Douglas Kramer, both from sunMicrosystems. According to the path composition module 407 of the present invention, it is determined that zero or more work requests are completed The application service path. In this respect, a work request is called a request object, which is illustrated by a level request. The level request has the following data components: inputState, outputState, and constraintExpression. The supported methods are as follows: getInput(), getOutput() and getConstraintExpression(). Generally speaking, most applications only perform very specific tasks, and therefore in most cases the service pool does not include a service that is fully matched to the user's request. Therefore, most of the time, the request can only be paired with one combination of application services. However, not every combination is desirable. Some paths may include slow services or may include expensive services. In particular, the task of the path composition system is to find a suitable combination of services that work within the constraints specified by the user. The path component module is implemented as a pathComposer object. This object provides the pathComposer.getpath(Request) method that will be reset or other paths that comply with the request.

The login 406 will register and deregister the application service, retrieve the application service according to the requested attribute, and return an identifier to request the service. To achieve this, log in a database that manages the available application services internally. The database contains records of application services, as shown in the table in Figure 5. All data of an application service is stored in the application service record presenting a row of the table. Each application service is described by a type, a global unique identifier (GUID) and a set of attributes. The style will give a general indication of the function completed by the service. Attributes define the characteristics of a service, such as the special function it performs, physical characteristics (such as location), and accounting characteristics (such as the price per print or the price per unit of data). All possible transitions from a first state to a second state that can be completed by a service can be extracted from the proper attributes of a service by using a syntax analysis device known in the art. An accounting chart can be defined by referring to one of a plurality of charts, or it can be defined explicitly by one of the examples shown in Fig. 5. Figure 5 will be fully discussed by the detailed elaboration of the example.

The registry also includes a table for mapping the GUID to an address in the address space of the networked system. Similarly, the registry also manages a database of service management components distributed on the network, such as, for example, a path component module.

The registration system is implemented as object registration. The methods that can be used to access data are getService(), getAttributes(), and getOutputStates(). The method registry.getservice(retrieval_criterion) will retrieve a service from login. This method will return an identifier used to satisfy one of the retrieval criteria ^。 The method registry.getAttributes(Service) will return attributes from a particular service. Finally, the method getOutputstates(service, inputstate) returns the output state, which can be obtained by providing a special service of a special input state.

When a path is provided, the transaction manager will request all required resources and control requests for all application services that are part of the path to achieve the purpose of actually completing the work.

The mobility manager manages the movement of an application service from one host to another.

Other distributed environments that need to manage the binding or creation of proxy servers are known in the art and will not be described in further detail here.

Job proposal processor

In the embodiment shown in FIG. 1, the user can define and propose a print job from a connected workstation as shown in FIG. 4. Since the beginning, a workstation has provided a print job proposal processor 405. When the print job proposal processor is implemented as a print job proposal application, or when a printer driver is activated in another application, such as a word processor 406, it can be directly requested by the user. operate. The print job proposal processor will now refer to Figure 6 and Figure 7 for a detailed description.

Figure 6a shows that it is presented to the user to define the day of operation under the control of the job proposal processor. The user inputs and manipulates the numerical value of the options in the day surface 601 to define the work. These options are: number of copies (602), color printing (603), binding (604), output paper (605), sort 3 sorting page number (606), density (607), enlargement ratio (608), all of which are detailed It contains the products that will be delivered by the work. Price ratio (609), security level (610), service reliability (611), sending location (612), and before printing (613) are all conditional restrictions defined by the user that must be completed. Of course, further restrictions are possible, such as the actual distribution of a mailing list. The operation day surface also includes a field (613) for inputting the file to be printed, and a message area (614) for displaying information related to work. Finally, a confirmation key (615) and a cancel key (616) are provided for the user to confirm that the work specification has been completed or his proposal to cancel the work.

Figure 7 represents a flowchart of the steps performed by the job proposal processor. When a print order or the like is initiated by the user, the job proposal processor will be requested (step 701). After the request, in step 702, the operation day surface as shown in FIG. 6 will be presented to the user for input of working parameters. After the confirmation key is activated, all the parameters of the print job, including possible preset values, will be collected. Next, in step 703, a request object is created and the request variables inputState, outputState, and constraintExpression are initialized with the collected parameter values. It should be noted that a formula that reflects the restriction input by the user is assigned to the constraintExpression request variable: R=NewRequest(inputState, outputState, constraintExpression) Next in step 704, the login is required to access a path component module: Registry .getService(type=pathComposer)

The registration will return a name (handle) to the path component module, and under the control of the registration, a proxy server of the pathfinder of the local station will be created.

Then in step 705, the path component module is required to return the path to the defined request: pathComposer.getListOfPaths(R)

In step 706, the path composition module returns a path list used to deliver the products specified by the job. In addition to all the paths found, the list contains a flag for each path value and each path of the restriction parameter in a constraintRecord to indicate whether compliance with the specified restriction exists. In the message area, the value of the limit parameter will be displayed for each path found. Figure 6b shows an example of this. The user can select a path by clicking on a pointing device on the area 617. If a large number of paths are returned, the system will provide the possibility of arranging these paths according to a restriction, and the user can click on one of the areas 618 with a pointing device. Under the conditions provided, the routes will be arranged according to price restrictions. The most attractive path regarding the price will be arranged at the top.

In step 707, the list will be checked whether it contains any paths. If the fact is true (Y), the method continues to step 708, in which the user is driven to select one of the paths. If the user selects one (Y), the method continues to step 709. In step 709, the transaction manager is called out and the selected path is provided. The transaction manager will request the required application services, and then request to complete the required services. The message returned from the requested service will be received by the transaction manager. The transaction manager will forward these messages to the client application, that is, the job proposal processor. The work proposal processor will display these messages in the message area of the operation day. When the job is completed and sent, it will also be displayed in the message area of the operation screen. In step 710, after the user confirms the message, the job proposal processor records the job data in a log file, and finally the method will exit.

If in step 707, the returned path list is empty (N), the path composition module returns a message indicating that the task cannot be performed under the requested product specification, and proceed to step 711. And if the user does not select a path in step 708, the method continues to step 711.

In step 711, the user is asked to modify the parameters belonging to the application. If the user responds negatively (N), the method exits at step 710 and no work will be completed. If the user accepts this feasibility (Y), the method proceeds to step 712, where after all the parameters are collected, the user edits the work specifications, and again in step 703, a new request object will be for example.

Path composition module

The getPath() method of the path component module will be described in detail with reference to the flowchart provided in Figure 8. The task of the getPath() method is to find out one of the application service paths that can complete a certain task within a given limit.

To achieve this, the method performs the following steps:

In step 801, when requesting the getPath method, the request R is transmitted. The initial state of the data object to be converted, the desired target state after the conversion is completed, and the restrictions that must be observed for the complete conversion are specified in the request.

In step 802, a queue object q, a chart object g, and a listOfPaths object will be exemplified and initialized. The object q and the object listOfPaths are exemplified from the List level that supports the addElement() method, hasMOreElements(), and getNextElement(). The AddElement() method adds an element to the list. If the list contains any elements, the hasMoreElements() method will return TRUE, otherwise it will return FALSE. The getNextElement() method returns the next element in the list and removes it from the list. At the beginning, the requested inputState will be arranged as an element in the queue object q.

The chart object g is an example from the grade chart. The objects exemplified from the hierarchical chart are used to store and process a directional chart. A node in the graph represents a state of a file, and a directional edge from a first node to a second node represents an application service used to transform the state of the first node to the state of the second node. Regarding the request, the chart object manages all the states that are reachable at a certain moment and required for application services during the execution of the getPath method. Figure 9 shows an example of a diagram that will be created during the execution of the getPath() method. The level chart supports methods such as setRequest(), addNode(), contains(), connect(), pathFound(), etc. The SetRequest method adds a node to the input state and stores the expression of Constraints. The addNode method adds a node to the graph. The Connect(Node1, Node2, Service) method adds an edge related to the application service that can complete this state transition from node 1 to node 2. Contains(Node) will check whether a node is included in the graph.

The above statement in step 802 will result in: q=new Queue() q=addelement(R. input) newg=Graph()g. setRequest(R)

In step 803, the queue will be checked whether there are any elements in it. If there is no (N), step 814 will be the next step. If the element (Y) is available, the next input state will be retrieved from the queue, and an input state transition can be completed. A list of application services (LAS) will be requested to log in in step 804 Middle: CurrentIn=q. getNextElement()LAS=Registry.getService(INPUT_STATE==currentIn)

Whether the search criteria of INPUT_STATE is completed will be checked for the "Conversion-suppprted" attribute of the service, as shown in Figure 5.

In step 805, the application service list (LAS) will be checked whether it contains any elements. If not (N), the method continues to step 803 to continue to enter the next input state. If it is (Y), in step 806, the next application service will be taken out of the list, and an output status list sent by the application service (LOS) at hand will form: CurrentService=LAS.getNextElement()LOS=Registry. getOutputStates(currentService,currentIn)

In step 807, whether the next element is available in the LOS will be checked. If not (N), the method proceeds to step 806 to continue with the next application service. If it is (Y), in step 808, an output state will be taken out of the list: currentOut=LOS.getNextElement()

And whether this state has been reached early will be checked: g.contains(currentOut)

If not (N), the method continues to step 809, in which the state is added to the queue and added to the graph as a node: q.addElement(currentOut)g.addNode(currentOut)

Next step 810 will be executed. If the result of step 809 is positive (Y), the method directly proceeds to step 810. In step 810, the current application service is treated as an edge and added to the graph: g. connect(currentIn,currentOut,currentApplicationService)

In step 811, whether a path from the input to the target exists will be checked: g.pathFound()

If the fact is not true (N), the method continues to step 806.

If a path has been found, the method continues to step 812. In step 812, the found path is obtained from the graph request. For each path, all parameters appearing in the constraintExpression will be calculated. Until now, for each service on the path, the contribution to the parameter value will be established, and then for each parameter, an overall value for the overall path will be calculated. These calculated values are stored in a constraintRecord in that particular path. Using these values, the constraintExpression will be evaluated, and if the result of the evaluation allows the realization to exist, a flag indicating the special path to achieve the required restriction will be set up, and a counter p will be repeated by 1 Increase. Tuple(path,constraintRecord,flag) will be added to listOfPaths as an element: listofPaths.addElement((path,constraintRecord,flag)) Then in step 813, the number of paths p to meet the required limit will be checked Is it greater than a starting value P. If the fact is true (Y), the method continues to step 814. In step 814, the list is passed back and the method exits in step 815. If the fact is not true (N), the method continues to step 806 to search for the next path.

If no path is found at all, the method follows the loop formed by step 811(N), step 806(N), step 805(N), and step 803(N), in which step 814 will be Lists that are reached and empty will be returned. Such an approach makes a complete chart of one of all suitable services will be a hindrance.

If the number of paths that meet the limit is less than the required number P (step 813:N), these paths will be added to the list in step 812 and will eventually go through steps 806, 805, and 803, and step 814 will be reached with the currently collected The list of paths will be transmitted.

The selectable number of repetitions from step 811 to step 806 can be limited to a certain maximum value, so that when this maximum value is reached, the method continues to step 814, in which all currently collected paths will be returned. This method avoids the time consumption created by the chart, if a large number of services are available.

Grade chart

An embodiment of a grade chart used in the system according to the present invention will be described with reference to FIGS. 8 and 9.

A hierarchical chart is used to illustrate a chart object, which represents a directional chart generated and initialized in step 2 of FIG. 8, and it is extended during the execution of steps 10 and 11 of FIG. 8. In the graph described in Figure 9, a node represents a state, and a directional edge from a first node to a second node represents a transition from the state of the first node to the second node Status of an application service. Regarding the request, the chart manages all the states that are reachable at a certain moment and required for the application service. At the beginning, the graph contains a starting node.

The data elements in a chart data that can be accessed by the outside world are: States, Request, Nodes, Edges, Services and Path, and these methods: setRequest(), addNode(), contains(), pathFound() and csnnect().

The internal elements of the chart are:

A vector v whose elements represent the nodes of the graph.

A matrix consisting of elements cij connected to C.

A reachable set containing state, which can be reached from the initial state, and a transformable set containing state, which can be converted to a target state.

One element vi of the vector v corresponds to the node ni of the graph. Each node represents a state. A state is represented by a vector s. The element si of a state represents a parameter i. An information object, for example, a document with a state determined by the actual values of a plurality of parameters. The edges representing one of the transitions from one state to another are stored in the matrix C. Each element (i, j) provides a transition from the state of node i to the state of node j.

The formation of a chart object will now follow the method request flow provided by getpath() for further explanation with reference to Figure 8.

In step 802, the graph object is generated via the following request: g=new graph() and then initialized via the request of the g.setRequest(R) method.

The parameters transmitted are: initial state s ₀ , Target state St and constraintExpression cE. Vector v gets two elements: S ₀ With St. Matrix C is only initialized with empty values. ReachabelSet is made up of the initial state s ₀ It is initialized, and the transformableSet is initialized by the target state st.

In step 809, the currentOut state or node is obviously not yet known, and the state is added to the reachableSet. And, requesting the g.addNode() method will complete the addition of adding the state to the vector, and upgrading one of the matrices will add an extra column and an extra column.

In step 810, the g.connect(currentIn, currentOut, CurrentApplicationService) method upgrades the matrix by comparing the indices of currentIn and currentOut by the self vector, and then adds currentApplicationService to the position of this index.

Next in step 811, transformabIeSet will be checked whether it contains a currentOut node. If the fact is true, in step 812, the pathFound flag is set and the method completes a graph cross-cutting algorithm to find the available path. Furthermore, all nodes that are part of a path are placed in a transformableSet. In this way, in the next repetition, when a node that has become part of a path arrives, it can be deduced that a new path has been found. The further steps of the GetPath() method have been discussed earlier.

example

The diversification of the system according to the present invention will now be explained by an example. The given ones are the application services registered according to Figure 5 and the image imaging system shown in Figure 1A. A state is defined as a collection of one of the parameter values typed clearly by a typewriter.

At the workstation 106, a user designates a print command to form a day surface as shown in Fig. 6a. The print file generated by the application on the workstation is encoded in emf (enhanced metafile) format.

According to the flowchart in Figure 7, in step 703, in the job proposal processor, a request object is generated: R=New Request(ssource,starget,cE) where source state ssource =(format:emf)target state starget = (format:A4,stapling:Y,number=100,sorted/collated=sorted)constraints cE =(price rate=&lt;15$)

Therefore, the input state is defined by format:emf; the output state is defined by format:A4 (implying printing), staping, sorted, and number of copies 100; and the restriction is (price rate =&lt;15$).

Next, in step 704, a pathfinder service is queried. A pathfinder service is available on the server 107, and then a proxy server for the pathfinder service is created at the workstation 106. Next, in step 705, the pathfinder is requested by the following request: Pathfinder.getpaths(R)

According to the flowchart provided in Figure 8, when the request is received in step 802, a queue q and a graph g are created and initialized: for the queue, the result is: q={s ₀ }, where s ₀ =s _sourc e=(format:emf)

And for the round table g, a node representing the initial state and a node representing the target state are created.

For the inside of the round table object, this means:

<maths><img file="TW511006B_D0001.tif" /></maths>

In the getPath() method in step 804, first an element in the queue is fetched CurrentIn=s ₀

Then the application service is queried (Figure 5), so that it can complete a one-shot exchange of the input state. A List of Application services (LAS) is returned at the end: LAS={as5}

After checking whether the LAS contains any combination element (Y) in step 805, as5 is taken from the list in step 806, and an output state list (List of output states, LOS) that can be transmitted via the application service is formed: CurrentApplicationService= as5LOS={s ₁ ,s ₂ } Where s ₁ =(format:PCL) and s ₂ =(format:HTML)

After checking whether the LOS contains any element (Y) in step 807, an element is taken from the list in step 808, and it is checked whether this element is already a node in the graph: currentOut=s ₁ g.contains(s ₁ )

This will return False(N). Therefore, in step 809, s1 is stored as a node in the graph and is added to the queue q and is added to reachableSet: q.addElement(s ₁ )g.addNode(s ₁ )reachableSet=(s ₁ ,s ₂ )

Next, in step 810, the transition from the currentIn state to the currentOut state via the currentApplicationService application service is stored as one of the directional edges in the graph.

g.connect(s ₀ ,s ₁ , as5) For the interior of the graph object g, the execution of steps 809 and 810 means that the node is added to the vector and reachableSet, and after the size of the matrix C is adjusted, currentApplicationService is added to the matrix. Regarding the internals of g, this will result in:

<maths><img file="TW511006B_D0002.tif" /></maths>

transformableSet={s ₁ } Next in step 811, the method will check whether the transformableSet contains a currentOut node. This is obviously not true, so pathfound: False so the method continues to step 807.

Element s2 is available in LOS (Y), so in step 808, this element is taken from the list, and the same order in steps 809-810-811 is executed as explained above.

This will produce q=(s ₁ ,s ₂ } And for the internals of g, this will result in:

<maths><img file="TW511006B_D0003.tif" /></maths>

Pathfound:False

In step 811, the Pathfound flag will be checked. This will again produce'FALSE' (N), so the method continues to step 807. In step 807, whether the LOS contains any output status will be checked. That is not true (N), so the method proceeds to step 805. In step 805, whether the list LAS contains any elements will be checked. This fact is not true (N). Therefore, the method proceeds to step 803. In step 803, whether the queue q contains any elements will be checked. This fact is indeed true (Y). In step 804, the next element in the queue will be retrieved and a ListOfApplicationServices (LAs) will be returned in this state: currentIn=s ₁ LAS={as3,as4}

After checking whether there is an element in the list (Y) in step 805, as3 is taken out of the list, and an output status list that can be transmitted via this application service is formed: currentApplicationService =as3LOS={s ₃ } Where s ₃ =(format:Postscript) Then steps 808-809-810-811 are executed, resulting in:

<maths><img file="TW511006B_D0004.tif" /></maths>

In step 811, the Pathfound flag will be checked. This will again produce'FALSE' (N), so the method continues to step 807. In step 807, whether the LOS contains any output status will be checked. That is not true (N), so the method proceeds to step 805. In step 805, whether the list LAS contains any elements will be checked. This fact is indeed true (Y). The method continues with as4 as the currentApplicationService. This currentApplicationService will produce an output state: LOS={s ₄ }Where S ₄ =(format:PDF) After processing steps 808-811, this will result in:

<maths><img file="TW511006B_D0005.tif" /></maths>

The method returns to step 803 (Y) via steps 807 (N) and 805 (N). In step 804, s2 is taken out of the queue q. Observing the register, it can be known that no application service with HPGL as an input state is available. Therefore, the method returns to step 803, where s3 is taken out of the queue q. Perform steps 804, 805, 806, 808, and 809 to produce:

<maths><img file="TW511006B_D0006.tif" /></maths>

This will lead to the situation in step 810, where

<maths><img file="TW511006B_D0007.tif" /></maths>

In step 811, a5 will be checked whether it is a superset of a state included in the convertible set. Indeed Starget is s ₅ Sub-collection. This will produce (Y): Pathfound=True

The method continues to step 812. In step 812, the found path is established. This will produce: (as5,as3,as1). ConstraintRecord will be determined for each limit parameter. Only the parameter "pay" will be specified. Therefore, the total price of the path found will be calculated. This will produce: constraintRecord=(pay:14$). Using the calculated value, the constraintExpression will be evaluated. This will produce TRUE. The resulting tuple is added to listOfPaths: This will produce: listOfPaths=(((as5,as3,as1,(pay:14$),TRUE)) In this example, we will assume P=2.

Next, in step 813, it will be checked whether p is greater than or equal to two. This fact is not true. Therefore, the next path must be found.

This will generate the path (as5, as4, as2, as1). And this path will be added to listOfPaths, resulting in: listOfPaths=(((as5,as3,as1),(pay:14$),TRUE),((as5,as4,as2,as1),(pay:13 $),TRUE))

Finally, in step 814, this list is returned to the job proposal processor. In step 708, the route will be displayed to be selected by the user and ordered by price, as shown in Figure 6b. The user chooses a path to continue the method as described earlier.

After the present invention has been fully explained at this moment, it is obvious that a person with ordinary skills in the art can make many changes and improvements based on the present invention without departing from the scope of protection of the attached patent application.

It should be noted that the present invention is not limited to text-type documents, and the present invention is equally applicable to various types of documents, such as documents containing only video information and audio information or a combination thereof.