JP2001243340A - Product definition in customer service processing system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the cost for realizing a new product or product function by speedily introducing the new product or speedily introducing the function change of an existent product. SOLUTION: In the product definition method and system in a client service processing system, a computing system is provided with plural client work stations 20 connected to plural servers and plural databases through a LAN 50. Meta-data products 100 and 201 are defined in the computing system 10. Respective products are plural actions 202 and are composed of plural product functions 204 and supply tasks 205. Such a product is prepared within 'definition time' and exists only as meta-data. At 'run time', real data are instantiated so that customer attributes are arranged in the product functions 204 and the product tasks 205.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

TECHNICAL FIELD The present invention relates to goods, services,
Or a computing system used for provision for information management. In particular, the invention relates to the definition of products in such a system.

[0002]

BACKGROUND OF THE INVENTION In modern large computing systems, the general topology is (i) a presentation layer featuring multiple workstations focused on user interaction, and (ii) application / business logic. And (iii) a data layer characterized by a plurality of databases that perform data storage and organization. A local area network or wide area network (LAN / WAN) interconnects the three tier elements.

[0003] Such computing systems have applications in many different fields, ranging from university research and educational facilities to business applications.
Virtually every business will use such a system to handle its business functions and serve its clients. For example, using one system, for word processing and accounting purposes,
Inventory can be managed to respond to client queries. Many businesses have a very large client base and offer large inventory of goods and services. An illustrative example is a telecommunications service provider (Te
lco). Thus, Telco may have millions of subscribers, and each customer will have access to any inquiries that may range from billing information to order status inquiries and to ordering of certain products. Expect an almost immediate response from a customer service technician (CSR).

[0004] Similar examples are public utilities, insurance companies, banks, hospitals, law firms, accounting firms, to name a few.
Found on stock exchanges, universities and government agencies.

[0005] All such computing
In a system, there is an inherent tension between software and hardware resources. As the demands of customers and the complexity of the goods and services offered increase, simply trying to increase the size of computing hardware is economically inefficient and technically limited.

[0006] Instead, there is a significant increase in system performance achievable by improving software coding, database management, and system firmware architecture. When scalability is to be achieved, all of these design elements need to be considered. "Scalability" refers to the ability of a three-tier computing application (in terms of the number and type of information passed between workstations, servers, and databases) to handle the growing volume of data, transactions, and user base. I do.

One approach to the problem of maintaining application program software is to use object oriented programs and a control framework database to regulate the execution of various programs by a certain classification scheme. Kaihei 10-326190
(IBM).

[0008] Part of this challenge is the need to create new products that should be available to customers.
This is only possible by making significant, time-consuming and expensive changes to the program code.
An example of a known arrangement is "Providing Telecommunication
JP-A-62-72253 (Nippon Telegraph and Telephone Corporation) named Service. This reference describes that communication functions / services are divided into elements called service parts. Service parts are assembled as tables to provide the desired service. However, such systems, and others like them, provide only limited answers to the above challenges, require complex behaviors, and provide the desired new products with interfaces to external systems. Can't cope.

[0009]

SUMMARY OF THE INVENTION The present invention seeks to overcome or at least ameliorate the problems of the prior art.

[0010]

SUMMARY OF THE INVENTION The present invention is a method for defining a metadata product residing in a client / server computing environment, the method comprising: (a) defining a product field; Steps and
(B) defining an action field within the product field; within the product action field; (i) defining a set of functional variables associated with the product; and (ii) defining a set of functional variables associated with the product. Defining a set of task variables.

The present invention is a data structure defining a metadata product residing in a client / server computing environment, the data structure comprising: (a) a product field; and (b) the product field. Action field in the
(I) a set of functional variables related to the product;
(Ii) an action field containing a set of task variables associated with the product.

The present invention relates to a product supply computer.
A method for providing a system, comprising: (a) defining a product as metadata; and (b) responding to an inquiry or order made on the computing system, the metadata version. Forming a real data version of the product by deploying the product.

[0013] The present invention relates to a product supply computer.
A system, comprising: (a) a plurality of client machines executing a supply application software;
(B) a plurality of server machines that also execute the application software, and (c) a network connecting the client machine to the server machine, wherein a product to be supplied is defined as metadata, and the client Further providing a computer system in which a real data version of the product is formed by placing the metadata version in response to a query or order made on the machine.

The present invention also provides for the definition of multiple product fields, each product field defining an action field therein. Each action field can be associated with an action field of a different related product field. The metadata product can be changed by modifying one or more of the functional variables or one or more of the task variables or a combination thereof. Metadata products can be associated with customers by placing customer attributes in function and task variables.

[0015]

FIG. 1 is a typical topology of a three-tier computing system embodying the present invention.
The presentation (or client / user) tier may be any suitable computing terminal, eg, a plurality of (1...) Personal computers.
n) represented by the workstation 20. The business tier can be a dedicated mini-computer or a mainframe computer (1.
p) is represented by the server 30. The data layer is represented by a plurality (1... M) of databases 40 that can include dynamically managed magnetic or optical storage media.

The computing system 10 includes:
It is of "open" design and has an external network 7
Communication links 60,6 to similar devices 22,32,42 and remote telephone terminals 24,26 via 0,72,74.
2, 64 are provided.

The workstation 20, server 30, and database 40 are interconnected by a local or wide area network (LAN or WAN) 50. The LAN / WAN 50 has the above 3
Convey information passing between each of the three basic elements. The topology shown in FIG. 1 is merely exemplary, and other convenient types of networks are feasible so that the purpose of the information passing between workstation 20, server 30, and database 40 is achieved. You can see that.

The embodiments of the present invention are industrially applied in the fields described in the above-mentioned "Prior Art". Telc operates across many U.S. states for non-limiting illustration
Consider the example of o. Such Telcos typically support local, regional, interstate and international voice and data calls as well as cellular mobile voice and data traffic. Telco customers can choose from a wide range of goods and services, including, for example, installing a second telephone / fax / internet line, call forwarding, and message exchange. The customer would also expect to be able to query the CSR located at the workstation 20 for billing and service failures. It is not unrealistic to expect modern Telco to have at least one million customers and typically require at least 500 CSRs. The infrastructure of a Telco system of this size can be expected to process about 15,000 business transactions per hour. Each business
Each transaction may require 6 CSR machine transactions, each machine
A transaction can involve up to 20 database transactions (ie, I / O).

To provide a better example of computing hardware of the size required to achieve such performance, CSR workstation 20 is a Pentium ™ running Windows NT ™ operating system. Server 30 is one or more IBM UN
IX ™ -based 12-way RS6000 ™
Can be an S-70 machine, database is Orac
Consider that it would require approximately 40 Gbytes of capacity managed by le ™ or IBM's DB-2 ™ system. Of course, there will be other operable LAN / WAN servers for handling data communications, as will be readily appreciated by those skilled in the art.

In business systems such as Telco, customers call CSRs and request goods or services in everyday language, such as a request to make "call waiting" available on domestic telephone lines. In fact, CSR is
It also performs this level of work, and information about such goods and services is presented (as a GUI) on the display of the workstation. Next, the computing system 10 operates on the goods or services or inquiries ordered by the customer.

One of the objects of the present invention is to achieve scalability. The system model adopted to help achieve this goal is "stateless."
This means that the data is passed to the server 30 and the database 40 without holding any record of the related information before the requesting side on the server 30. In other words, all system transactions are contained on their own without having to be aware of any user or system transactions previously performed in the server for this user.

Another related aspect is a design choice that does not force the workstation 20 to communicate with only one particular server 30. Rather, any information request from the workstation 20 can be directed to any one of the "p" servers 30. further,
Only the server 30 can access the “m” kinds of databases 40.

Another design choice is the use of object-oriented programming that allows for componentization. Object-oriented programming is characterized by reusability, low (software) maintenance, ease of understanding, and extensibility. Thus, this allows the linking of related actions as a building block of the process state.

The principles of object-oriented programming were published by Addison-Wesley in December 1998.
`` The Unified Modeling Language Reference Manu '' by James Rumbaugh, Ivar Jacobsen, and Grady Booch
al "(ISBN 0-201-30998-X).

The "goods and services" supported by system 10 are referred to as "products." A product is metadata that exists inside both the workstation 20 and the server 30 of the computing system 10. The product is composed of “action” and “tagged action”. Each action has a "feature" and a "supply task", each of which consists of an "attribute".

At this time, it is useful to introduce the concepts of “defined time” and “order management time”. The definition time relates to the definition of a new product (or a modification of an existing product) up to the point where it becomes available for association with a customer. In addition, the order management time is based on the CS of the workstation when the new product is valid.
This is the case when it is put on the market to be usable by R. At the order management time, the "actual" operated to perform a product supply action or a database query
Objects are instantiated to place data into a defined product template.

A product is defined during a defined time so that it can be used by the CSR to place instances in response to customer orders. As shown in FIG.
The product 100 is a mapping process 11 that becomes a series of tasks 120 to perform on the product.
Multiplied by zero. Tasks reside in server 30 and database 40 and can return values to product actions. The returned value updates product action status information and configuration function attributes.

FIG. 3 illustrates the interaction of various "process subsystems". "Product definition" 130,
The subsystems “Pricing” 135 and “Supply Definition” 140 are created during the defined time. "Customer products"
The subsystems 145 and "Supply Runtime" 150 occur only during order management time.

The product definition subsystem 130 includes a number of meta data products, and for illustrative purposes, shows a "calling card" product definition. "Calling Card" must be at least "Wireline Access"
(Required) with the product (shown as dashed lines). Also, this is "Adding a calling card"
It also has a product action definition, and the configuration functions are "scheduling", "calling card", "memo",
“Service number” and “charging”.

The pricing subsystem 135 has a billing plan definition, and the related functions are “global options”,
"Exchange fees" and "Executive staff privileges".

The supply definition subsystem 140 also provides for each product action (in this case, the calling
Have a supply activity plan (showing only the card) and the specific tasks associated with it
Relates to the actual work that needs to be performed to supply additional cards. These tasks include "network activation", "billing update", "service number assignment",
It is described as "service business dispatch."

The order management time calls for the calling card service performed on the CSR (in this case)
Joe Smith's request (in Product Subsystem 145)
Started by This results in a calling card add action (of Joe Smith). CSR is
Ask Joe Smith about the specific calling card functional requirements: "calling card", "service number", "memo", "scheduling", and "billing". The billing function also queries the stored calling card billing plan record and retrieves the appropriate information to be relevant to the action.

Next, the request is submitted to the supply runtime subsystem 150 for supply. The supply activity plan is instantiated for the "add calling card" action and takes its format from the supply definition subsystem 140 where the attributes collected in the customer product subsystem 145 are located as described above. Next, "Activating Joe's Network" and "Joe
A series of tasks called "dispatch of service business" are executed. When these tasks are performed, “Joe Smith's Calling Card” is activated in Customer Product Subsystem 145, and the “Service Number Function” and “Calling Card Function” are associated with it. Associated with existing "wireline access products".

Products Products can be defined to meet the needs of a particular business or customer. In that sense, an existing product can be modified in some way or a new product can be added to the Product Book, which is a logical grouping of products, such as those that can be sold to resident customers. It is. The following products can be considered as products in the Telco environment.

Standard Wireline Access: A wireline connection into a home that allows the home to have a physical phone product.

Incoming call: The ability to notify a customer that another call has arrived while a call is in progress.

Call Forwarding: The ability to reroute a telephone call to another telephone / mail box / pager, etc.

Standard Wireless Access: Connection to a cellular telephone system.

Referring again to FIG. 2, product 100 includes (a) actions and, optionally, (b) tagged actions. Actions are based on specific customer accounts /
You can "add" or "remove" a particular product for a service, or change the configuration of that product.

The actions are, for example, the location of the service (LOS) and the network identifier (NI)
And related functions. The function defines the data instance to be collected. An action also has an associated supply activity associated with the task (electronic and possibly also specifying human intervention) required to perform the action.

It should be noted, however, that an individual action can have a relationship to one or more or a group of other product actions. Such relationships are captured by "tagged" actions. This allows the sales agent to associate the two actions without any explicit knowledge of the relationship from a CSR perspective. For example, Telco may want to make sure that a maintenance contract is associated with wireline access sales. In this case, a tagged relationship is created between the two product actions (ie, “add maintenance contract” and “add wireline access”), and when selling the wireline access product, the maintenance contract is also The CSR does not need to explicitly remember that it has to sell, but rather means that it will be prompted.

Mapping process 110 for a product (if its attributes are located) to a task
Involves the use of task mapper keys. An "attribute" is a data unit used to associate a product with a task. The task mapper key format is conveyed by the instantiation form of the product template.

Tasks The task domain 120 functions at a lower-level abstraction that describes meta-states. Tasks represent work that needs to be completed to perform a product action (whether as an inquiry or as a product supply). The tasks are ordered as a graphical structure called a "task plan".

From an object-oriented point of view, an instance of a task is an object. The definition of a task is a class (ie, programmed code). The data that makes one task instance different from the other is read from database 40 when instantiating the task.

Within a supply activity plan, a given task functions as a milestone. These can be scheduled as checkpoints to ensure data validity during the correct progress of the workflow. At these checkpoints, messages are sent between the product domain and the task domain to align them and determine if they are valid for the continuation of the system process. Examples of how such milestones fit into them, for example,
Service Number Assignment (SNA) activity is that milestones after the “Service Number Assignment” task may have to guarantee that the Service Number Data Element (Product Function) is valid. Otherwise, the system should not be able to go beyond its "Service Number Assignment" activity milestone. In this case, if the service number function is not enabled, the milestone will fail and supply will not be able to continue. Rules regarding when product features should be locked are defined during the product definition time. That is, for a given product action, the product function will be locked to the given milestone, preventing further updates by the CSR.

Examples Product Definitions The first example of a new product definition relates to Telco offering a new "Standard Wireline Access" (SWA) product to customers.

The following steps define this product and should be read in connection with FIG.

Step 201 (essential): Create a product and call it "Standard Wireline Access".
This creates a product object named "Standard Wireline Access".

Step 201 (a) (optional): "Prerequisite product" enables designation of another product which is a prerequisite for adding this product. For example, call forwarding for wireless access cannot be defined unless standard wireline access is first defined.

Step 202 (required): Create an action for "Standard Wireline Access", name it "Connect", and define its type to be a predefined action type "Add". . this is,
Create an action object and associate it with a "standard wireline access" object.

Step 203 (optional): Create an “add” action for the product as a tagged relationship to the “maintenance contract” 209. This is accomplished by selecting a maintenance contract-add product action from a list of previously created product actions.

Step 204 (essential): Create a product function relationship and add it to the "connect" product action.

Step 204a: Select the "Service Location" function from the predefined list of Function 1. This creates a location function definition for the service that is associated with the Connect product action.

Step 204b: Select a "network" function from a predefined list of functions. This creates the network function definition associated with the Connect product action.

Step 204c: Select the "service number" function from the predefined list of functions. This creates the service number function definition associated with the "Connect" product action.

Step 204d: Select a "directory" function from a predefined list of functions. This creates the directory function definition associated with the "Connect" product action.

Step 204e: Select the "schedule" function from the predefined list of functions. This creates the schedule function definition associated with the Connect product action.

Step 204f: Select the "charging" function from the predefined list of functions. This creates a billing function definition associated with the Connect product action.

Step 205 (required): Create supply milestone tasks / milestones and add them to the “connect” action 2.

Step 205a: Select the "start point" milestone from the predefined list of supply tasks / milestones. This creates the starting point milestone definition associated with the "Connect" product action.

Step 205b: Select "Submitted" milestone from predefined list of supply tasks / milestones. This creates a submitted milestone definition to be associated with the "Connect" product.

Step 205c: Select the "started supply" milestone from the predefined list of supply tasks / milestones. This creates an out-of-stock milestone definition associated with the "Connect" product.

Step 205d: Select the "switch office connection" task from the predefined list of supply tasks / milestones. This creates an exchange connection task definition associated with the "connection" product.

Step 205e: Select the "Activate Service" milestone from the predefined list of supply tasks / milestones. This creates the service activation task definition associated with the "Connect" product.

Step 205f: Select the "supply completed" milestone from the predefined list of supply tasks / milestones. This creates the supply complete milestone definition associated with the "Connect" product.

Step 205g: Select another supply task.

Step 206 (not shown): Associate "standard wireline access" with the "resident" product book. Products are added to the product book for sale by CSR.

Step 207 (not shown): The product is tested. A series of tests are performed to prove the integrity of the product structure.

Step 208 (not shown): Market the product. "Standard Wireline Access" is now available for CSR to view and sell.

Note 1: This list is built from a list of product features already associated with the "Standard Wireline Access" product and a list of product features specifically set up to directly relate to product actions. . One of the attributes of each product function is a reference to the desired supply milestone to which the function must be locked (see one of the activities of step 205).

Note 2: This is a partial list of the total number of possible tasks to be supplied, representing a typical milestone.

FIG. 5 shows the instantiated form (ie, at order management time) of the product template shown in FIG. 4 for the SWA-C product action. Instantiated LOS, N, S
The attributes of the N, S, and C functions are as follows.

[Table 1]

[Table 2]

[Table 3]

A supply activity plan for connecting Joe Smith's standard wireline access is created when a request for supply is submitted.

Task Mapping Instantiated Product Action Mapping Process 110 for “Task Plan”
Involves the use of task mapper keys and associated task templates. Basically, the steps to follow are as follows.

1. The task mapper key is built from among the attributes of the instantiated product template (eg, FIG. 5).

2. For each configuration provisioning activity, the correct task template is found (between pre-stored and defined libraries).

3. Task plans are built from configuration task templates and made available for execution as a sequence of specific work tasks.

An example of the mapping process will now be described with reference to the object interaction diagram of FIG.

Task Mapper Key A task mapper key is a specific subset of attributes related to product actions whose values are used to identify the specific task that must perform a supply operation. It is.

The server process instructs construction of a task mapper key (MapToTasks ()) for the SWA-C action. Except for those designated as milestones,
Consider each supply activity 205 in turn.

For simplicity, consider only the "switched connection" supply activity 205d. In the case of this activity, the getTaskMapperKeyDefinition () command changes the definition format of the exchange connection 205d to "Region & SwitchID & Exchange
Search for the string "ID".

The getActivityDefinitionID command searches for the string "value" from the definition format of the exchange connection 205d.

Next, the getAttributeValue () command is
Executed for each parameter (ie, Region, Switch ID, Exchange ID) obtained from the runtime version of "Joe Smith's Service Location"204'a and "Joe Smith's Network"204'b.

The activity definition ID in this example is “123”. The task mapper key definition is "Region & SwitchID & Ot
her ", and"&"is a separation operator. Activity definition I
D is a value that replaces the "Joe Smith's exchange connection" activity. The number of required keys held in the activity definition ID is
In this example, it is “2”.

The task mapper key is “Yorktown & Swi
tch2 & AAA ".

Task Template Detection A predefined list of task templates is maintained in the database 40, each of which is a global task
Represents a sequence of work tasks that form part of a plan.

SearchForRow (ActivityDefinitionID, Tas
kMapperKey) command is executed.
The mapper key is compared to a set of task templates.

The database is searched for an activity definition ID and a task mapper key. Therefore, the search is 123, "Yorktown & Switch2 & AA
A ”. Consider the extracted database items.

[Table 4]

If there is a direct match, the "task template detected" state has been reached. However, for these items, the search yields Nill's results. In such cases, the search is limited and the adjust Task
The Mapper Key () command will be invoked. Since the number of required keys is "2", the task mapper key will be "Yorktown &Switch2", in which case the third row of the above database entries will match and provide the task template.

If, after all optional keys have been discarded, there is still no match between the reduced task mapper key and the task template, SearchForD
The efaultRow (ActivityDefinitionID) command is called, which causes the default
The task template is retrieved from the database 40.

At this time, the task template has been detected.

Forming a Task Plan Each task template specifies a sequence of work tasks. In the case of Joe Smith's exchange connection activity,
The task template is “Yorktown & Switch2”
This corresponds to the task connectexchange.

For a modern telephone exchange, it may be sufficient to issue a single task. In other older exchanges, dispatchtechnician, disconnect, connec
There may be a required set of tasks, such as tswitch2, callback to mainexchange.

The process described in FIG. 6 is repeated for the remaining supply activities of FIG. 5, and the completed task plan is built as a sequence of elementary tasks.

As far as supplementary information is concerned, it specifies who will perform the work defined by the task. Based on the task template, an additional search for this information is made against other database tables. The "work" could be performed automatically at the local exchange, or it might require a technician to install the physical wiring and supply the handset. If no such information is found, default information is used.

Function Attribute Locks When implemented, a task plan is executed / supplied, with database access as well as individual work actions. Supply includes the concept of "attribute locks" associated with task milestones.

To illustrate the application of attribute locking, consider again the example of Joe Smith requesting a product action from a CSR on Monday, "Joe Smith's Standard Wireline Access Connection". Joe
Has specified that the requested connection date will be the next Thursday. This corresponds to the scheduling function 204 shown in FIG.
e is a configuration attribute of e. This action is submitted for provisioning and the task plan is implemented. One specific task is to have a technician at the exchange connect the appropriate circuits. If Joe calls the CSR on Thursday and requests that the connection date be extended, it is desirable to "lock" its functional attributes so that they cannot be changed at such a late stage.

For the "Standard Wireline Access-Connect" product action, the following table should be read in connection with FIG. 7 and shows an example of a sequential task.

[Table 5]

The task plan of FIG. 7 is executed sequentially until it reaches a milestone task. At this point, a query is first made of the product action related function to determine if it is valid (ie, related to customer information). If it is not valid, the task plan cannot continue. If the particular milestone detected is to be held by the function as an indication that a lock is to be taken, the "function locked status flag" is set to true (see also FIG. 3), An acknowledgment is returned to the milestone task so that the supply can continue. If this flag is set, then
The attribute of the product function cannot be changed, and the attribute is in the "locked" state. If the task milestone does not correspond to a milestone held by a feature, the task plan can still continue and the feature remains in the "unlocked" state.

FIG. 7 shows the relevant supply activity milestones maintained by each product function (in addition to the task plan). In the case of the SWA-C example of connecting on Thursday, a milestone of "supply started" 254 is relevant. That is, when the PS milestone has passed, the scheduling function sets the locked status flag, and the “customer request date” cannot be changed.

Another aspect of the locking process is to allow the customer to be notified that "the switch connection will be made today".
The ability of the CSR to query the progress of the provisioning task.

Product Definition and Order Management Dialogue with the Computing System FIGS. 8 and 9 illustrate the product product and product management as described above with respect to the client workstation 20, server 30, and database 40, and particularly with reference to FIG. 5 is a self-evident flow diagram for a defined time activity.

FIGS. 10, 11 and 12 are similar self-explanation regarding order management activities, as described above in connection with client workstation 20, server 30, database 40, and particularly with reference to FIGS. 4-7. It is a flowchart of.

[0104]

The product definition method described above offers a number of advantages. First, it allows for the rapid introduction of new products or the functional change of existing products. Second, the cost of implementing a new product or product function is reduced. Third, complex functions are encapsulated in product-independent functions.

In summary, the following items are disclosed regarding the configuration of the present invention.

(1) A method for defining a metadata product residing within a client / server computing environment, comprising: (a) defining a product field; and (b) defining a product field within the product field. Defining an action field, (i) defining a set of functional variables associated with the product, and (ii) defining a set of task variables associated with the product within the product action field. A method that includes (2) 1 related to different said product fields
The method of claim 1, further comprising linking one or more other action fields to the product action field. (3) The method of (1) above, wherein modifying one or more of the functional variables changes the metadata product. (4) The method according to (1), wherein the metadata product is changed by modifying one or more of the task variables. (5) The method according to (1), wherein the metadata product is changed by modifying one or more of the function variables and one or more of the task variables. (6) The method of (1) above, further comprising associating the metadata product with a customer by placing attributes on the functional variables and the task variables. (7) A method for defining a set of metadata products residing in a client / server computing environment, comprising: (a) defining a plurality of product fields; and (b) for each product field. Defining an action field therein, within each said product action field (i) defining a set of functional variables associated with the product, and (ii) a set of tasks associated with the product. Defining a variable. (8) 1 related to the different product fields
The method of claim 7, further comprising linking one or more other action fields to the product action field. (9) The method according to (7), wherein the metadata product is changed by modifying one or more of the functional variables. (10) The method of (7) above, wherein modifying one or more of the task variables changes the metadata product. (11) The method according to (7), wherein the metadata product is changed by modifying one or more of the functional variables and one or more of the task variables. (12) The method of (7) above, further comprising associating the data product with a customer by placing attributes on the functional variables and the task variables. (13) In a data structure that defines a metadata product existing in a client / server computing environment, the data structure includes (a) a product
A field, and (b) an action field within the product field, comprising: (i) a set of functional variables associated with the product; and (ii) a set of task variables associated with the product. A data structure that contains action fields. (14) The data structure according to (13), further comprising an action field associated with a different product field and linked to the product action field. (15) The data structure according to (13), wherein the metadata product is changed by modifying one or more of the function variables. (16) The data structure according to (13), wherein the metadata product is changed by modifying one or more of the task variables. (17) The data structure according to (13), wherein the metadata product is changed by modifying one or more of the function variables and one or more of the task variables. (18) The attribute (1) described above in (1), which is further related to the customer, by arranging attributes in the function variable and the task variable.
Data structure described in 3). (19) In a data structure defining a set of metadata products existing in a client / server computing environment, (a) a plurality of product fields, and (b) for each of the product fields, An action field, wherein each action field comprises: (i) a set of function variables associated with the product; and (ii) an action field including a set of task variables associated with the product. The data structure to include. (20) The data structure according to (19), wherein the metadata product is changed by modifying one or more of the function variables. (21) The data structure according to (19), wherein the metadata product is changed by modifying one or more of the task variables. (22) The data structure according to (19), wherein the metadata product is changed by modifying one or more of the function variables and one or more of the task variables. (23) The attributes described in the above (1), which are further related to the customer, by arranging attributes in the function variables and the task variables.
The data structure according to 9). (24) A method for providing a product serving computer system, comprising: (a) defining a product as metadata; and (b) in response to a query or order made on the computing system. Forming a real data version of the product by placing the metadata version. (25) Step (a) includes defining a product field, defining an action field within the product field, and (i) defining a set of (i) associated with the product within the product action field. The method of (24), wherein the method is performed by defining a function variable and (ii) defining a set of task variables associated with the product. (26) The method of (25), further comprising linking one or more other action fields associated with a different said product field to said product action field. (27) The method according to (25), wherein the metadata product is changed by modifying one or more of the functional variables. (28) The method according to (25), wherein the metadata product is changed by modifying one or more of the task variables. (29) The method according to (25), wherein the metadata product is changed by modifying one or more of the functional variables and one or more of the task variables. (30) The method of (25) above, further comprising associating the metadata product with a customer by placing attributes on the functional variables and the task variables. (31) In a product supply computer system, (a) a plurality of client machines which execute supply application software, (b) a plurality of server machines which also execute the application software, and (c) the client A network connecting the machine to the server machine, the product to be supplied being defined as metadata, and placing the metadata version in response to an inquiry or order made on the client machine A computer system on which a real data version of a product is formed. (32) The computer system of (31) above, further comprising an action field associated with a different product field and linked to said product action field. (33) The computer system according to (31), wherein the metadata product is changed by modifying one or more of the function variables. (34) The computer system according to (31), wherein the metadata product is changed by modifying one or more of the task variables. (35) The computer system according to (31), wherein the metadata product is changed by modifying one or more of the function variables and one or more of the task variables. .

[Brief description of the drawings]

FIG. 1 is a diagram illustrating an exemplary topology of a three-tier computing system embodying the present invention.

FIG. 2 is a diagram showing a meta state mapping between a product and a task.

FIG. 3 is a diagram showing subsystems executable in a product domain.

FIG. 4 is a flowchart showing a state relating to a product definition.

FIG. 5 is a diagram showing an instantiated product.

FIG. 6 is an object interaction diagram for the task mapping process.

FIG. 7 illustrates a task plan with an attribute lock.

FIG. 8 is a flow diagram of a new product definition associated with a computing system element.

FIG. 9 is a flowchart of a new product definition associated with a computing system element.

FIG. 10 is a flow diagram of order management times associated with computing system elements.

FIG. 11 is a flow diagram of order management times associated with computing system elements.

FIG. 12 is a flow diagram of order management time associated with a computing system element.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 10 Computing system 20 Workstation 22 Similar device 24 Remote telephone terminal 26 Remote telephone terminal 30 Server 32 Similar device 40 Database 42 Similar device 50 Local area network or wide area network (LAN or WAN) 60 Communication link 62 Communication link 64 Communication link 70 External network 72 External network 74 External network

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Joan Burns New Zealand Auckland, Tovey, Wesley Road, 44 (72) Inventor Russell Joan Beatson Christchurch, New Zealand, Avonside, Wildwood Avenue 4 (72) Inventor Ahmed Fatter 2065 New South Wales, Australia, St. Leonard, Pacific Highway 601 (72) Inventor Joan Edward Wilkinson Wellington, Kandalar, Indus Street, New Zealand 8 (72) Inventor Jacqueline Helen・ Morgan Christchurch, New Zealand North New Bra Ton, Beach Road 32 (72) Inventor Alan Alexander Maxwell Baroque Place, Christchurch, Iran, New Zealand 8 (72) Inventor Christopher Mark Green Warwickshire CV37 7JH, England, Stratford-upon-Avenue, Britt Judgetown Road 1a (72) Inventor Bijesh Bergwan Nandia, Auckland, New Zealand Mount Eden, View Road 4/69 (72) Inventor Gregory James Alarm Alarm, Auckland, New Zealand, Remuera, Ringers Street 1F Terms (reference) 5B049 BB11 BB47 CC02 CC05 DD05 EE05 FF03 FF04 FF09 GG04 GG07 5B075 KK03 KK07 KK13 KK33 KK37 ND20 ND36 NK46 NK54 PP30 PQ00 QT03 UU40 5B089 GA11 GB03 JA33 JB22 JB KB KB

Claims (35)

[Claims] 1. A method for defining a metadata product residing in a client / server computing environment, comprising: (a) defining a product field; and (b) an action in the product field. Defining a field within the product action field, (i) defining a set of functional variables associated with the product, and (ii) defining a set of task variables associated with the product. Including methods. 2. The method of claim 1, further comprising linking one or more other action fields associated with a different said product field to said product action field. 3. The method of claim 1, wherein modifying one or more of the functional variables changes the metadata product. 4. The method of claim 1, wherein modifying one or more of the task variables changes the metadata product. 5. The metadata product is modified by modifying one or more of the functional variables and one or more of the task variables.
The method of claim 1. 6. The method of claim 1, further comprising associating the metadata product with a customer by placing attributes on the functional variables and the task variables. 7. A method for defining a set of metadata products residing in a client / server computing environment, comprising: (a) defining a plurality of product fields; and (b) defining each product field. For each field, define an action field therein, within each of the product action fields: (i) a set of functional variables associated with the product; and (ii) a set of functional variables associated with the product. Defining the task variables of the first. 8. The method of claim 7, further comprising linking one or more other action fields associated with a different said product field to said product action field. 9. The method of claim 7, wherein modifying one or more of the functional variables changes the metadata product. 10. The method of claim 7, wherein modifying one or more of the task variables changes the metadata product. 11. The method of claim 7, wherein modifying the one or more of the functional variables and one or more of the task variables changes the metadata product. 12. The method of claim 7, further comprising associating the data product with a customer by placing attributes on the functional variables and the task variables. 13. A data structure defining a metadata product residing in a client / server computing environment, the data structure comprising: (a) a product field; and (b) an action item in the product field. A data structure comprising: an action field comprising: (i) a set of functional variables associated with the product; and (ii) a set of task variables associated with the product. 14. The system of claim 1, further comprising an action field associated with a different product field and linked to said product action field.
3. The data structure according to 3. 15. The data structure of claim 13, wherein modifying one or more of the functional variables changes the metadata product. 16. The data structure of claim 13, wherein modifying one or more of the task variables changes the metadata product. 17. The data structure of claim 13, wherein modifying one or more of the functional variables and one or more of the task variables changes the metadata product. . 18. The data structure according to claim 13, wherein attributes are assigned to the function variables and the task variables to further relate to customers. 19. A data structure defining a set of metadata products residing in a client / server computing environment, comprising: (a) a plurality of product fields; and (b) for each of the product fields: An action field therein, wherein each of the action fields
A data structure whose fields include: (i) a set of functional variables associated with the product; and (ii) an action field including a set of task variables associated with the product. 20. The data structure of claim 19, wherein modifying one or more of the functional variables changes the metadata product. 21. The data structure of claim 19, wherein modifying one or more of the task variables changes the metadata product. 22. The data structure of claim 19, wherein modifying one or more of the functional variables and one or more of the task variables changes the metadata product. . 23. The data structure according to claim 19, wherein attributes are arranged in the function variables and the task variables to further relate to customers. 24. A method for providing a product serving computer system, comprising: (a) defining a product as metadata; and (b) responding to a query or order made on the computing system. By placing the metadata version, the real data
Forming a version. 25. Step (a) comprises defining a product field; defining an action field within said product field; within said product action field: (i) one associated with said product; 26. The method of claim 24, wherein the method is performed by defining a set of functional variables, and (ii) defining a set of task variables associated with the product. 26. The method of claim 25, further comprising linking one or more other action fields associated with a different said product field to said product action field. 27. The method of claim 25, wherein modifying one or more of the functional variables changes the metadata product. 28. The method of claim 25, wherein modifying one or more of the task variables changes the metadata product. 29. The method of claim 25, wherein modifying one or more of the functional variables and one or more of the task variables changes the metadata product. 30. The method of claim 25, further comprising associating the metadata product with a customer by placing attributes on the functional variables and the task variables.
The method described in. 31. A product supply computer system, comprising: (a) a plurality of client machines that execute supply application software; (b) a plurality of server machines that also execute the application software; A network connecting the client machine to the server machine, wherein a product to be provided is defined as metadata, and a metadata version is arranged in response to an inquiry or order made on the client machine Computer system by which a real data version of a product is formed. 32. The system of claim 3, further comprising an action field associated with a different product field and linked to said product action field.
2. The computer system according to 1. 33. The computer system of claim 31, wherein modifying one or more of the functional variables changes the metadata product. 34. The computer system of claim 31, wherein modifying one or more of the task variables changes the metadata product. 35. The computer-readable medium of claim 31, wherein modifying one or more of the functional variables and one or more of the task variables changes the metadata product. system.