WO2002021357A2 - Systeme de deroulement du travail - Google Patents

Systeme de deroulement du travail Download PDF

Info

Publication number
WO2002021357A2
WO2002021357A2 PCT/GB2001/004022 GB0104022W WO0221357A2 WO 2002021357 A2 WO2002021357 A2 WO 2002021357A2 GB 0104022 W GB0104022 W GB 0104022W WO 0221357 A2 WO0221357 A2 WO 0221357A2
Authority
WO
WIPO (PCT)
Prior art keywords
work
job
entity
entities
factor based
Prior art date
Application number
PCT/GB2001/004022
Other languages
English (en)
Inventor
Neil Geoffrey Smith
Chrystelle Claire Ruinat
Original Assignee
Ilangua.Com Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ilangua.Com Limited filed Critical Ilangua.Com Limited
Priority to AU2001284301A priority Critical patent/AU2001284301A1/en
Publication of WO2002021357A2 publication Critical patent/WO2002021357A2/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/10Office automation; Time management

Definitions

  • the present invention relates to a work flow system, in particular to a system for use in the translation industry.
  • the translation industry works to a traditional, client - agent - translator, model. This is a relationship intensive operation with the agent managing relationships with the client and translator. The situation can become more complex with multiple clients, multiple translators, editors, proof- readers etc. Many steps in the process are administratively time-consuming and wasteful.
  • LTC produce a stand-alone software package to manage the translation process and maintain a database of translators .
  • the invention provides a system for facilitating workflow.
  • the inventive idea comprises three aspects :
  • the first inventive aspect resides in measuring the quality of work in a workflow system.
  • the second inventive aspect resides in scheduling resources and identifying the best resources for a job.
  • the third inventive aspect resides in providing quotations for work to be done.
  • Fig. 1 shows the relationship between a client, agent and translator
  • Fig. 2 shows the steps in submitting and completing a job
  • Fig. 3 shows further detail in submitting and completing a j ob
  • Fig. 4 is a diagram showing the key data stores used in a system embodying the invention
  • Fig. 5 is a diagram showing the functional relationship between the key data stores
  • Fig. 6 shows the user database in greater detail
  • Fig. 7 shows the stored calender in greater detail
  • Fig. 8 shows the transaction database in greater detail
  • Fig. 9 shows the job database in greater detail
  • Fig. 10 is a logical diagram of how jobs are specified
  • Fig. 11 shows how data attributes are stored
  • Fig. 12 is a diagram showing production of a quality measure for a translator
  • Fig. 13 is a diagram showing production of a quality measure for an agency;
  • Fig. 14 shows the key aspects of job presentation;
  • Fig. 15 shows the production of a list of prospective translators;
  • Fig. 16 is a further view of production of a quotation; and Fig. 17 shows a job queue.
  • the embodiment of the invention described is a workflow system for the translation industry incorporating the three inventive aspects discussed above. Nonetheless, it will be readily appreciated that the system may be applicable to other industries, and that each of the three aspects may be used separately or in any combination.
  • the system is beneficial for those in a work entity: client entity relationship.
  • work entity refers to an entity that undertakes and completes work on behalf of another.
  • an entity includes a translator or translation agency or other provider of foreign language services such as interpreters. Other entities could include cleaners, cleaning companies and so on. Nonetheless, the system and methods described are particularly beneficiali to the translation industry.
  • client entity can be an agent to whom a translator provides completed work, or a client to who the agent provides completed work. The client entity in a given relationship is thus the entity for whom work is completed.
  • the system includes a process and technological model that mirrors and supports the entire translation process from the ground up. Contrary to existing solutions, rather than providing a surface layer of automation, the system encapsulates all aspects of the process and provides the foundation layer of technology.
  • the system is able, in real time, to advise translation agents in their placement and fulfilment of work. Through further configuration, this advice can be extended to allow for a fully automated system of quotation and placement of work.
  • the system By working at the abstract layer of translators skills and experience, translation job specification and scheduling, the system is able to provide much higher value to agents.
  • the automatic quantification and qualification of the measures and trends associated with the process enables the system to provide objective indications of the quality of participants in the network.
  • the preferred system is an online system based on standard Web protocols, HTTP and HTML. These underlying technologies and protocols are not necessary to implement such a system, but they ensure that access to the system is available to any individual who has access to the Internet.
  • the system provides a personal interface for each participant in the translation process, giving them a personalised view of their role in the process and the components that make up the process.
  • the relationship between client, agent and user is shown in Figure 1.
  • the first step is to prepare a job specification 10, and submit this to an agent to analyse 12.
  • the agent- selects an appropriate agent to verify availability 14, and then prepares a quotation 16.
  • the client can then consider the quotations 18, and assign the job 20.
  • the agent then offers the job to translators 22, who prepare quotations 24, so that the agent can assign the job 26, and the translators commence translation 28.
  • completion is proposed 30, accepted by an agent 32, proposed to the client 34, and finally accepted by the client 36. This process is used in the embodying system and particular key parts will be described later.
  • the life cycle of a translation job has been used to identify the key stages of a translation job life cycle as shown in Figure 3.
  • the first stage is to specify a new job 40, which will be described in greater detail later.
  • a job is then either under tender 42, or in progress 44.
  • Stages towards completion in percentage term 46, are defined and ultimately a job is completed 50 and either accepted 52, or not accepted 48.
  • the final stages are received at the client 54, accepted by the client 56, invoice sent 58, invoice paid 60, and job complete 62.
  • the life cycle we have devised is used within the system to enhance workflow operations. This will be understood by now discussing the main components of the system with reference to Figure .
  • Figure 4 shows the key logical components.
  • the system comprises a database 100, which comprises four logical areas. These areas store the data relevant to operations of the three inventive aspects.
  • the key data store 100 comprises a job database 102, a user database 104, a shared calender store 106 and a transaction database 108. All data stored within the system is stored in one of these data stores. The way in which the data is stored is within the knowledge of the skilled person. As an example, the Python programming language is used and the stores are relational databases.
  • the interrelationship between the four stores and the remainder of the system is shown in Figure 5.
  • the heart of the system is a workflow engine 110 which comprises a set of processes to receive orders, select appropriate translators, complete jobs and all the functions provided by the system including the three inventive aspects.
  • a user, agent or translator connects to the workflow engine 110 using a browser 112 using standard web techniques within the knowledge of the skilled person.
  • the workflow engine thus comprises a set of computer routines.
  • the key routines are the reputation engine, resource engine and quotation engine. These respectively provide the functions of: means for devising a measure of quality, means for determining a subset of work entities and means for providing a quotation. Each of these is a program routine.
  • the user database 104 shown in Figure 6 has separate stores for a user ID 114 and user information 116, which itself comprises further stores for personal details 118, and addresses 124. In addition, for translators, stores are provided for qualifications 120, experience 122 and rate- cards 126.
  • the user database thus comprises all the data required for the workflow engine to select and contact translations and enables preparation of quotations and quality measures.
  • the stored calender store 106 shown in Figure 7 stores an indication of the availability of translators. This is achieved by storing the user ID 114 along with a calender 128 indicating the availability of that user.
  • the store could hold an indication of availability other than a calender, but a calender is preferred.
  • the transaction database 108 comprises two stores: agency track records 130 and translator track records 132. This information relates to past jobs and is used in three situations. The most important is for use by the quality engine to generate quality measures for translators and agents. The second is to enable billing of the users of the system. The third is to provide management information about the jobs that have been completed within the system.
  • the last of the four stores is the job database 102 shown in Figure 9.
  • the Job Database 102 stores all the relevant information about job specifications 136 and the quotations 138 that agents have provided against those specifications.
  • a job specification ⁇ onsists of a number of document sets and within each document set there are potentially a number of documents.
  • a document has associated with it a list of source languages (srclang) and a list of required target languages (dstlang) .
  • the client will have indicated the specialisation of the text of the document (e.g. legal, medical, financial) .
  • the quotation and completion deadlines whether the translator should retain the original layout, the file formats used, the word count, the purpose of the translation, whether special confidentiality requirements exist, how the document is to be delivered, the editors and proof-readers etc.
  • a quotation identifies a particular job and provides a summary of the costs to perform the work. As well as a price for the work, the quotation provides any additional information about the conditions that the agent has assumed in providing the quotation. For example, if the client was unaware of the original language of the document, then the agent will recognise it and add that information to the quotation.
  • the system operates on the data stored in the four logical areas according to three main processes, each relating to one of the three inventive aspects. These processes are: reputation engine; resource engine and quotation engine. These will be described later with reference to further figures.
  • the first step is to create a job as shown in Figure 10.
  • a Job can be considered as a container that stores all the relevant information associated with an item of work. This information includes, who created the job, who is managing the job, the deadlines for the provision of quotations and the completion of the job.
  • a Job contains at least one Document Set, and each Document Set contains at least one File. The job information is stored in the job database 102.
  • a job may consist of one or more DocumentSets.
  • a DocumentSet collects together the files that are needed to complete one part of a translation job.
  • a DocumentSet has a number of VirtualDocumentSets, one for each target language of a Document contained within the DocumentSet. Each of these VirtualDocumentSets can be considered independently or as a single unit allowing the translation agent to assign work and monitor deadlines on an individual or combined basis.
  • the Job and DocumentSets are shown in Figure 10.
  • a number of files are contained within a DocumentSet. Each file serves a specific purpose:
  • Each file is stored along with the owner and a ⁇ set of permissions that have been determined by the owner, giving or restricting access to the file. If a user has access to a particular file then they are able to download it from the system to their own machine.
  • Documents Files that have to be translated are referred to as Documents.
  • Each Document has a word count, source language, target languages, taxonomy classification etc. and can be assigned a specific deadline.
  • the agent is able to assign a translator on a Document by Document basis or for the whole of the VirtualDocumentSet .
  • Information about Jobs, DocumentSets, Files and Documents is stored in an RDBMS in the Jobstore 102.
  • the high level data structures available within the chosen Python language are not representable in most typical RDBMS systems. For this reason a special base class has been developed.
  • a DBBackedDict acts like a persistent Python dictionary storing attribute : value pairs in an RDBMS.
  • Each sub-class of a DBBackedDict must list the attributes that correspond to the simple data structures (Integer, String, Float etc) . The values that correspond to these attributes are then stored under the normal RDBMS column headings. Any other attributes are assumed to be complex and are stored together in a Binary column where the complex attribute : value pairs are stored in a marshalled Python dictionary. This is shown in Figure 11.
  • An electronic translation taxonomy assists with the classification of a translation job and with the skills that translators have. All fields of expertise are categorised and sub-categorised. This allows the clients or agent to specify which sub-category a particular piece of translation work falls into.
  • Translators who have built up their reputation in the system will have that reputation associated with doing a particular kind of translation work.
  • the taxonomy allows the system to match translators and their skills to the work in question.
  • the taxonomy is a hierarchical structure and translators are assumed to be proficient in any field of expertise higher up the hierarchy.
  • the Translation Quality Meter provided by the quality engine shown in Figures 12 and 13 is a method of aggregating static and dynamic information to provide an opportunity to objectively compare the quality of different translation resources.
  • the system keeps a record of every completed piece of work stored in the translation database 108.
  • this is defined as being the end of each specific document translation, whereas in the case of agencies it is the completion of a specific job.
  • An entry in the translator' s track record corresponds to a row in an RDBMS.
  • the row looks like this:
  • the specific document and job are recorded, along with the date completed, the agent that managed the job, the translators identifier, the source and target language, classification, whether the job was on time and the agent's satisfaction rating.
  • An entry in the agency' s track record corresponds to a row in an RDBMS.
  • the row looks like this:
  • the specific job is recorded, along with the date completed, the client, agency and agent, whether the job was on time and the client's satisfaction rating.
  • the Reputation or Quality Engine is used to calculate a reputation for any agency, agent or translator participating in the system.
  • the translator reputation is shown in Figure 12 and relies on a combination of qualifications, experience, client satisfaction, tests and the translators track record within the system.
  • the engine extracts data from the user/translator database 104 and transaction/job database 108 to extract the following factors:
  • the algorithm for determining the quality rating is thus:
  • the greatest portion of the quality measure is thus the track record which we consider an "objective” measure.
  • the other indicators are "subjective” measures. We appreciated that the better indicators in a work flow system are objective. Accordingly, other formulae could be used with the greatest weight given to objective, rather than subjective measures.
  • Each indicator is a parameter stored in one of the four databases as previously described.
  • the percentage of repeat business, number of jobs completed, and the percentage of occasions when work is delivered in time are also broken out and form part of the reputation.
  • the qualifications indicator contribute to the translators reputation in the following way:
  • a translator will claim a certain number of years of experience. This will contribute to their reputation. In addition, when they ask to become certified, their experience will be validated and their score improved.
  • the experience indicator is:
  • the translators track record makes the greatest contribution to their reputation as it is the most ⁇ objective measure of their quality.
  • the translators track record is calculated over the last two years worth of jobs that they have completed in the system and is compiled from three factors with are multiplied together.
  • a repeat business indicator is calculated by dividing the number of repeat business jobs by the total number of jobs. For example:
  • Times Used value the value for each agency that the translator has worked for is calculated, and the highest value taken.
  • the reputation algorithm 140 combines these factors to produce the quality measure. Combining these factors, imagine a translator working for the agencies as. listed below:
  • the reputation engine can be used to derive a reputation indicator for an agency.
  • the reputation engine for an agency shares some common features with the reputation engine for a translator. As shown in Figure 13.
  • a number of factors are taken into account to build the Business Factors component of the Agency Reputation. Each of these factors is assigned a value and the values are weighted and combined. The values are taken from the profile that the agency manager enters when they register the agency with the system.
  • a number of bands are used to give scores according to the number of years in business.
  • a number of bands are used to give scores according to the number of full-time employees .
  • the agency' s track record makes the greatest contribution to their reputation as it is the most objective measure of their quality.
  • the agency's track record is calculated over the last three years worth of jobs that they have completed in the system and is compiled from three factors with are multiplied together.
  • a repeat business weighting is calculated by dividing the number of repeat business jobs by the total number of jobs. For example:
  • Times Used value the value for each client that the agency has worked for is calculated, and the highest value taken.
  • the system brings all the participants together, clients, agents and translators, and monitors their progress as they complete jobs, it is able to automatically identify appropriate resources to complete a specified translation job. This is performed the resource engine, a routine within the work flow engine. At the point where the system has found a number of appropriate resources, the clients or agents are able to specify that they would like the system to make a decision on their behalf, or they are able to reserve judgment and pick from the short-list that has been put together for them.
  • the criteria for resource identification are a combination of practical measures, for example, the languages required and time availability, and more abstract measures, their electronic reputation.
  • the resource engine can both identify and schedule appropriate resources for a given job.
  • the process starts by taking the tuple (srclang, dstlang, classification) representing the source language, destination language and classification for the Document being considered.
  • tuple srclang, dstlang, classification
  • a search is made against the Translator Database and the Agent's Address Book to generate a list of likely translators. Within the Translator Database, this search is done based upon the rate-card configuration that the translators have made.
  • the rate card is as follows :
  • the system then examines the diary of each of the translators to determine whether they have enough time available to complete the translation in question.
  • the time required is determined by the number of words to translate and the word rate that the translator can manage. Any translators that could not complete the job in the time available are eliminated. If at this point the list of potential translators is too short then a second search is done against the entire Translator Database to see whether there are suitable translators who are not in the Agent's Address Book. Again the diaries of these translators are checked.
  • the complete list of potential translators is then displayed so that the agent can select who they would like to have complete the work.
  • the translators availability and their electronic reputation are also made available to the agent, along with their rates.
  • Each of the translators in the system has a calendar that allows them to indicate their availability to the agencies they work for.
  • the translators maintain these calendars and update them when they take on new work.
  • the calendars indicate a proportion of their time that they have available each day.
  • the system is able to automatically cross-reference the calendars to see which translators are appropriate and amongst them, who is available, requiring no further attention from the translation agent.
  • the system For each of the prospective translators the system takes the size of the job and divides it by the word count that translator is able to achieve each day. This indicates the number of days work required. The system then looks at the translator's calendar to see if they have indicated that they are available for a sufficient period of time between now and the completion deadline for the job.
  • the resource engine requires jobs to be analysed and prioritised as shown in Figure 14.
  • This prioritization is calculated dependent upon the information specified in the job, the size of the job, the stage of the job, the job deadline etc.
  • the priority of a job is calculated by taking the number of words left to translate and dividing this figure by the number of days left until the job completion deadline.
  • the translator is responsible for updating the system as they make progress on a job.
  • the different stages that a job can go through have a notional correspondence to the amount of work left to do.
  • the table below describes this correspondence:
  • the client Having created a Job by uploading the necessary Files and Documents to the system, classifying the type of work and setting deadline etc. the client is then ready to request quotations for that Job.
  • the Client is able to select which agents they wish to quote for a job by accessing the Agency Directory.
  • the Agency Directory contains details of all the Agencies registered with the system. Each Agency records specific information about their company and the system itself also maintains long term trend information to generate the Electronic Reputation associated with the agency. The client is given all this information and they are then able to select which agencies they wish to have bid for the work.
  • the agent's pre-configured system can analyse the job specification and attempt to automatically provide a quotation for the client. If the source and target languages, along with the classification have been specified by the client in the job and the agent has configured this information in their account, then an automatic quotation can be provided.
  • the system takes the tuple of (srclang, dstlang, classification) , the source, destination languages and classification and performs a comparison against the list that makes up the agent's pre-configured rate-card. If -any of the tuples matches and the autoquote flag is set to True, then the system is able to proceed to the next step. This involves taking the wordcount for the document and dividing it by the number of words that the agent can complete per day. This gives the total elapsed time required for the job.
  • the system calculates whether the job can be completed at a 'normal' rate, 'rush' rate or 'weekend' rate.
  • the automatic quotation then consists of the word count of the job multiplied by the price configured by the agent for that type of job.
  • the rate card is as previously described:
  • Job may contain many different DocumentSets with many different Documents in each Set and each Document may have a different source and target language pair and classification, this process is repeated for each Document. This may lead to a partial quotation if the Job has not been fully specified.
  • Every participant in the system may have many jobs that they are working on at the same time.
  • the jobs are associated with each account and are simply stored as a list of strings that correspond to the Job Id numbers .
  • each job is identified by a string containing two parts. The first corresponds to the day that the job was created, starting counting at a suitably defined epoch period. The second part is a monotonically increasing integer assigned for each new job.
  • the Job Id's that are stored in the Job Queues correspond to Jobs in the database where the Job Id is used as the Primary Key.
  • the Job Id is used to fetch the row in the database which is then manipulated through a DBBackedDict.
  • the quotation mechanisms that are used in the system can take account of special cases that are typical in the translation industry. These special cases typically revolve around the fact that a client wants a job completed more quickly than is usually possible.
  • a normal rate of work is 2,000 words per day.
  • the agent is able to specify a different rates depending upon the source and target languages and the classification.
  • the system takes the time available to complete the work (that is, the amount of time between the quotation deadline and the job completion deadline) and determines whether Copper it is possible to -complete the job at the standard rate of work.
  • the system will look to see whether the work could be completed if the translator were to work over the weekends. If this is the case, then the weekend rate will be applied.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
PCT/GB2001/004022 2000-09-08 2001-09-07 Systeme de deroulement du travail WO2002021357A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001284301A AU2001284301A1 (en) 2000-09-08 2001-09-07 Work flow system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0022073A GB2371377A (en) 2000-09-08 2000-09-08 A work flow system
GB0022073.1 2000-09-08

Publications (1)

Publication Number Publication Date
WO2002021357A2 true WO2002021357A2 (fr) 2002-03-14

Family

ID=9899105

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2001/004022 WO2002021357A2 (fr) 2000-09-08 2001-09-07 Systeme de deroulement du travail

Country Status (3)

Country Link
AU (1) AU2001284301A1 (fr)
GB (1) GB2371377A (fr)
WO (1) WO2002021357A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005033968A1 (fr) * 2003-10-08 2005-04-14 Lexxicorp Pty Limited Procede et systeme de devis pour traitement de texte

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005033968A1 (fr) * 2003-10-08 2005-04-14 Lexxicorp Pty Limited Procede et systeme de devis pour traitement de texte

Also Published As

Publication number Publication date
GB2371377A (en) 2002-07-24
AU2001284301A1 (en) 2002-03-22
GB0022073D0 (en) 2000-10-25

Similar Documents

Publication Publication Date Title
US20210233032A1 (en) System and method for evaluating job candidates
US5802493A (en) Method and apparatus for generating a proposal response
US7769774B2 (en) System and method for focused routing of content to dynamically determined groups of reviewers
US6742002B2 (en) Computer-implemented and/or computer-assisted web database and/or interaction system for staffing of personnel in various employment related fields
US20050060283A1 (en) Content management system for creating and maintaining a database of information utilizing user experiences
WO2008089077A2 (fr) Procédé et appareil destinés à des applications d'engagement distribué et de mise en commun coopérative dans un système d'emploi
JP2009169968A (ja) 消費者の寄付に基づいて市場の需要を判定するための方法およびシステム
KR20030047859A (ko) 협력필터링 및 웹스파이더링을 이용한 검색용어추천
US20020083024A1 (en) Case management system and method
US8108428B1 (en) Vendor/client information system architecture
JP2004213147A (ja) 翻訳管理装置及び翻訳管理システム
US20020055937A1 (en) Immigration case management system
WO2002021357A2 (fr) Systeme de deroulement du travail
JP2003022382A (ja) ジョブ仲介システム及びジョブ仲介方法
Desharnais Statistical analysis on the productivity of data processing with development projects using the function point technique
EP1290605A1 (fr) Procede et systeme d'impartition en technologie d'information
US20030065547A1 (en) Information processing apparatus, information management system, information management method, storage medium, and program product
EP1671205A2 (fr) Systeme de gestion de contenu pour la creation et le maintien d'une base de donnees d'information faisant appel aux experiences des utilisateurs
Schmieley 91-14676 L II/i/i! IIIII! IIII!,; iU; o
Bowen et al. Ex Ante Evaluations of Alternate Data Structures for End User Queries
Hartmann et al. An expertise system for supporting the sales and distribution process of a software vendor
CA2591239A1 (fr) Verification de logement lors d'un congres

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP