JP2007133861A - Intellectual property management system, method for drawing attention, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an intellectual property management system capable of completely changing the names of clients given to accepted matters. <P>SOLUTION: When a matter is accepted, certain client data in a client master is selected by a client user, is added to matter data, and registered in a matter database. Thereafter, if the client inputs a notice of a change of a client name to a server, as when informed that a change in actual data about clients, such as a client name, has occurred, then a client master registering part updates the client name in the client master of a client master database. Immediately before an application procedure for the case, a history code in the client data registered in the matter database along with the matter data is compared by an attention drawing determining part to a history code in the client data of the client master; when the history codes are determined not to match, a determination is made that attention should be drawn. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an intellectual property management system, an alerting method, and a program for managing information related to matters such as patents using a computer.

  In recent years, to create intellectual property rights (proposals) such as domestic and foreign patents, utility model registration, design registration and trademark registration, application, examination request, deadline management such as intermediate processing for reasons for refusal, pension management after registration, etc. The usefulness of the intellectual property management system is increasing. Such an intellectual property management system includes functions for expiration management and annuity management, a function for outputting such management information, a function for issuing various notifications, and the like (eXtensible XML). Markup Language) Application-compatible electronic application system, package management system that centrally manages a large amount of intellectual property documents, patent information retrieval system that enables retrieval by keywords by accumulating a large amount of intellectual property documents, Some allow for linkage with other systems, such as a billing management system that manages issuance and the like.

  In the intellectual property management system, customer information such as the name of a customer (applicant, agent, etc.) as a client is centrally managed by a customer master and shared among the respective departments of the system. On the other hand, each case stored in the case database is also provided with information about the customer, and when the case is received, the customer master is read to add the information about the customer to the information about the case.

  When a change such as a customer name occurs, the change is usually made to the customer master. After that, the registration of the matter accepted from the customer to the matter database is changed based on the customer master. The later customer name is added to the case. On the other hand, for cases that are already registered in the case database before the customer name change, the person in charge calls the bibliographic entry screen for the case at any time (for example, during the application process) and manually enters it. The customer name was corrected. That is, the person in charge needs to change the customer name without fail for the case that has been accepted with conscious attention, and the human burden has been great.

As a mechanism that can reduce the burden on the person in charge, there is a technology that visually alerts the person in charge at the necessary timing. For example, in Patent Document 1, regarding the display of the schedule screen, along with various bars indicating the progress of tasks / jobs, a bar for defining checkpoints and events necessary during the progress of the project is displayed. It is stated that it is necessary to call attention to whether you have to finish your work by that time.
Japanese Patent Laying-Open No. 2003-141320 (paragraph 0042, FIG. 13)

  In a conventional intellectual property management system, when a customer name or other change occurs, the person in charge of the system must consciously change the customer name assigned to the case that has been accepted without omission. There is a problem that this becomes a heavy burden and the business efficiency is lowered. In addition, if there is a change in the progress of the procedure for an application, such as a notice of reasons for refusal, withdrawal of an application, or amendment of an application that has already been filed, let the person in charge of the system quickly recognize this. Depending on the case, the following actions must be taken promptly. However, no mechanism has been realized that alerts the person in charge of the system regarding changes in the progress of the procedure for an application. In addition, there was no means for notifying the person in charge without leaking the precautions when there were any precautions regarding the matters for each customer.

  In addition, the conventional intellectual property management system has a mechanism for immediately knowing whether or not there is information (for example, memos, related information, whether or not a referee is in progress) other than the basic screening process for a given case. There wasn't.

Furthermore, due to the processing method at the time of transfer of the case at the time of company split, etc., management omission has occurred for intermediate processing. For example, let us consider a case where there is a company B established by splitting from company A and company A. In this case, Company A, the applicant of Project X, transfers the project to Company B, and Company B becomes the contract holder (contractor's right holder), and the name is changed to the Patent Office. If the procedure is not performed, for Company A, Project X becomes a transfer project and becomes the jurisdiction of Company B, but Company A (the right holder on the procedure) needs to perform procedures such as intermediate processing for the JPO. . However, Company A may miss a necessary procedure for Item X because it is a transfer item. Similarly, the agent of Project X will also make an inquiry to Company A who is the right holder in the procedure, and will make another inquiry from Company A to Company B who is the contractual right holder.

  In view of such circumstances, the present invention provides an intellectual property management system, an alerting method, and a program capable of preventing omission of changes in actual data related to a customer such as a customer name assigned to a case that has been accepted. Objective.

  In order to solve the above problems, the intellectual property management system of the present invention describes, as data relating to a customer, a customer code for identifying the customer, actual data relating to the customer, and a history code indicating a history of changes to the actual data. A customer master storage unit in which the customer master is stored, a case database in which data related to the case is selected from the customer master stored in the customer master storage unit together with data related to the customer related to the case, Compare the customer-related data stored in the matter database and the customer-related data described in the customer master with those that have a common customer code, and if the history codes do not match, there is a difference in the actual data about the customer. It is characterized by comprising alerting means for outputting alerting information of a certain thing.

  Further, the alerting means may be activated when an inquiry request for data related to the matter occurs.

  According to the present invention, it is possible to inform the user in the form of alerting the user that the actual data related to the customer such as the customer name has occurred after the acceptance of the case, for example, during the case application procedure. . As a result, it is possible to prevent the occurrence of an error such that the application procedure is advanced using the old customer name before the change.

  In addition, the present invention provides a setting file storage unit that stores a setting file in which a condition for alerting a change in procedure progress status of an application item is stored, and progress data update that acquires information related to a change in procedure progress status of an application matter A reminder file that contains a word of alert when a change in the procedure progress status of the application that was acquired by the information acquisition unit and the progress data update information acquisition means matches the alert condition described in the settings file And a reminder screen generating unit that generates a screen including a word for alerting based on the alert file generated by the alert determination unit. . Thereby, the update contents of the progress status of the case can be confirmed.

  Further, the present invention provides an input unit for inputting matter-based alert data or customer-unit alert data, and an item-unit alert data or customer-unit alert data input from the input unit. A reminder data storage unit to be memorized; an instruction input means for inputting an instruction to call an alert data for each project or an alert data for each customer; and an alert data for each project instructed by the instruction input means or It may further comprise alert data output means for reading out and outputting alert data for each customer from the alert data storage unit. This makes it possible to input special item data for each project and special item data for each customer in a graphical environment, and easily access and view registered special item data by clicking the button with a mouse. be able to.

  Further, according to one aspect of the present invention, the data related to the case stored in the case database includes data of a plurality of items, and the alerting means refers to the case database to determine the item holding the data And the alert information for this item is output. As a result, it is possible to immediately know the presence or absence of information that occurs in addition to the basic examination flow for an arbitrary case.

  Further, according to one aspect of the present invention, information related to the customer's history can be registered in the customer master storage unit, and the alerting means is connected to the contractual rights holder based on the information related to the customer's history. It is characterized by determining whether or not the right holder is procedurally matched, and outputting alert information indicating this in the case of a mismatch. As a result, it is possible to reduce the occurrence of oversight of necessary procedure processing for a case transferred from a procedural right holder to a contract right holder.

  According to the intellectual property management system, the alerting method and the program of the present invention, for example, in the case of the application procedure for the case, the fact that the customer data such as the customer name has been changed after the case was accepted It can be communicated in the form of alerting the user. As a result, it is possible to prevent the occurrence of an error such that the application procedure is advanced using the old customer name before the change.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a block diagram relating to an alerting process in the intellectual property management system according to the first embodiment of the present invention.

  The intellectual property management system 100 includes, for example, a CPU (Central Processing Unit) that executes a program, a ROM (Read Only Memory), a RAM (Random Access Memory) that is a main memory that stores a program or data being executed, Server / client system configured by organically connecting multiple computers composed of storage devices such as hard disk drives that store programs and data, input devices such as keyboards and mice, and display devices through communication lines It is realized by the network system.

  The intellectual property management system 100 according to this embodiment includes a server 10 and a client 20. The server 10 and the client 20 are connected through a network 30.

  The client 20 includes a display unit 21 that displays an inquiry screen and an input screen for various data related to the item and the customer, and an input unit 22 that allows the user to input various data related to the item and the customer on the input screen displayed on the display unit 21. And have.

  The server 10 includes a data receiving unit 11, a case data registration unit 12, a customer master registration unit 13, a case database 14, a customer master database 15 as a customer master storage unit, an alert determination unit 16 (attention means), and alert information. An addition unit 17 (attention calling means) and a data transmission unit 18 are included.

  The data receiving unit 11 is means for receiving, for example, various requests, item data, customer data, and the like transmitted from the client 20.

  The case data registration unit 12 is a means for performing processing for registering the case data given from the client 20 in the case database 14.

  The customer master registration unit 13 registers the customer data given from the client 20 in the customer master database 15 and updates the customer data already registered in the customer master database 15 with the data given from the client 20. Means.

  The case database 14 is a database in which case data is accumulated. Customer data selected from the customer master when the case is accepted is added to the case data.

  The customer master database 15 is a database that holds a customer master. In the customer master, a customer code 31 for identifying a customer, a history code 32 indicating a history of change of actual data related to the customer, and actual data 33 related to the customer such as a customer name are registered as customer data. The history code 32 is expressed by, for example, a value indicating the number of changes, a change date, and the like. The actual data 33 relating to the customer includes an address, a telephone number, a postal code, and the like in addition to the above customer name. In this embodiment, for simplicity of explanation, only the customer name is handled.

  The alert determination unit 16 receives, for example, customer data and customer data added to the case data registered in the case database 14 when a request from the client 20 such as a case inquiry before the application procedure occurs. The customer data registered in the master are compared with each other having a common customer code to determine match / mismatch, and when the mismatch is determined, the client 20 changes the customer data. It is a means to judge performing alerting about. More specifically, both history codes are to be compared.

  The alert information adding unit 17 displays predetermined alert display information on a screen such as a case inquiry screen to be displayed on the display unit 21 of the client 20 when the alert determination unit 16 determines to alert. It is a means to add. The item inquiry screen is a screen on which bibliographic items and the like related to one item are displayed for each item, and each item is a screen that is a text box in which data can be input. The alert display information may be in any form as long as it can alert the user to the customer data change.

  The data transmission unit 18 is a means for transmitting, from the server 10 to the client 20, for example, an inquiry screen for various data such as case data and customer data, and a completion notification for registration / change of various data.

  Next, the operation of the intellectual property management system 100 of this embodiment will be described.

  FIG. 2 is a diagram showing an overview of the alerting process in the intellectual property management system 100 according to the first embodiment. When the case is accepted, any customer data in the customer master is selected by the user of the client 20, added to the case data, and registered in the case database 14. Thereafter, the client 20 receives the customer name from the client 20 to the server 10 when receiving a notification that a change in actual data regarding the customer such as the company name (customer name), organization name, and address (contact address) of the customer has occurred. When the change notification is input, the customer master registration unit 13 updates the customer name of the customer master in the customer master database 15. Immediately before the case application procedure, the history code in the customer data registered together with the case data in the case database 14 is compared with the history code in the customer data of the customer master by the alert determination unit 16, and there is a mismatch. Is determined to call attention.

  The details of each operation at the time of acceptance, change of the customer master, and application procedure in the above-described alerting process will be described below.

  FIG. 3 is a flowchart regarding the operation at the time of acceptance in the alerting process.

  First, the client 20 sends a request with a customer code to the server 10 for acquiring customer data to be added to the case data of the accepted case on the case registration screen where information on the case can be input for each item (step S301). ). When the data receiving unit 11 receives this request, the server 10 extracts corresponding customer data from the customer master held in the customer master database 15 (step S302), and this data is sent to the client 20 by the data transmitting unit 18. (Step S303). Upon receiving the customer data, the client 20 confirms the contents of the customer data on the screen, and then transmits a request for registration of the case data input on the case registration screen to the server 10 (step S304). When the server 10 receives the request for registration of the case data at the data receiving unit 11, the case data registration unit 12 performs processing for registering the case data in the case database 14 (step S305). After completion of the registration of the case data, the server 10 notifies the client 20 of the completion of registration of the case, and when the user of the client 20 confirms the registration completion using the input unit 22 (step S306) This process ends.

  FIG. 4 is a flowchart regarding the operation when the customer master is changed in the alerting process.

  The client 20 transmits a request for the corresponding customer data to the server 10 when receiving a notification that a change in the customer's company name (customer name) has occurred (step S401). This request is made by specifying the target customer by the customer code. When the server 10 receives the customer data request at the data receiving unit 11, the server 10 extracts the corresponding customer data from the customer master stored in the customer master database 15 (step S402), and sends the customer data to the data transmitting unit 18. To the client 20 (step S403). In the client 20, the contents of the received customer data are displayed on a customer data inquiry screen or the like. Here, the user uses the input unit 22 to input the changed customer name data notified by the customer, and transmits a customer master update request including the changed customer name data to the server 10 (step S404). When the server 10 receives the client master update request from the client 20 at the data receiving unit 11, the customer name of the customer master held in the customer master database 15 with the customer name change data included in the customer master update request. And the history code value is incremented (step S405).

  For example, it is assumed that the original customer data of the customer master is customer code: 1231, history code: 001, customer name: TOIC. When customer name: TSOL occurs as change data, the actual data of the customer name in the customer master is updated to “TSOL”, and the history code is updated (incremented) from “001” to “002”.

  After the update of the customer master, the server 10 notifies the client 20 of the completion of the update of the customer master. When the user of the client 20 confirms the completion of the update using the input unit 22 (step S406), the customer master The change process ends.

  FIG. 5 is a flowchart regarding the operation at the time of application procedure of the alerting process.

  First, the client 20 transmits a request for a case inquiry screen for a case that is the subject of the application procedure (step S501). When the server 10 receives this request at the data receiving unit 11, the server 10 reads the corresponding item data from the item database 14 (step S502). Here, the alert determination unit 16 extracts customer data of the same customer from the customer master of the customer master database 15 based on the customer code included in the customer data in the case data read from the case database 14. (Step S503). For example, if the customer code included in the customer data in the item data extracted from the item database 14 is “1234”, the customer data including the same customer code “1234” is extracted from the customer master.

  Subsequently, the alert determination unit 16 compares the history code included in the customer data in the case data extracted from the case database 14 with the history code included in the customer data extracted from the customer master. As a result of this comparison, if the two history codes are different, it can be considered that the customer name has changed after acceptance of the case, so the alert determination unit 16 determines that alert is to be issued. . When it is determined that the alerting determination unit 16 performs alerting, the alerting information adding unit 17 adds predetermined alerting display information to the case inquiry screen that responds to the client 20 (step S504). Then, a case inquiry screen to which the alert display information is added is transmitted to the client 20.

  Further, when both the history codes coincide with each other, the alert determination unit 16 determines that alert is not performed. In this case, only the case inquiry screen is responded to the request from the client 20. . The client 20 receives the case inquiry screen from the server 10 and displays it on the display unit 21 (step S505). If alert display information is added to the case inquiry screen, the user of the client 20 can know that the customer data of the case has changed based on this information, The operation can be shifted to the operation of updating the customer data with the customer data of the current customer master. Thereafter, the client 20 inputs information for the application procedure of the present case (step S506), and the server 20 receives the request and processes the application procedure (step S507).

  As described above, according to the present embodiment, it is possible to inform the user in the form of alerting the user that a change in the customer name has occurred after acceptance of the case during the case application procedure. As a result, it is possible to suppress the occurrence of errors such as proceeding with the application procedure using the old customer name before the change.

  In this embodiment, the change of the customer name has been described. However, actual data related to other customers that need to be described in the application can be handled in the same manner.

  Next, a second embodiment of the present invention will be described.

  FIG. 6 is a block diagram relating to an alerting process in the intellectual property management system according to the second embodiment.

  The intellectual property management system 200 according to this embodiment includes a server 40 and a client 50. The server 40 and the client 50 are connected through the network 30. The client 50 includes a display unit 51 that displays an inquiry screen and an input screen for various data related to the case and the customer, and an input unit 52 that allows the user to input various data related to the item and the customer on the input screen displayed on the display unit 51. And have.

  The server 40 includes a data reception unit 41, a progress data update information acquisition unit 42, a case database 43, a reminder condition master 44, a reminder determination unit 45, a front page generation unit 46, and a data transmission unit 47.

  The data receiving unit 41 is a means for receiving various requests such as user login requests, case data, and the like transmitted from the client 50.

  The progress data update information acquisition unit 42 is connected to the subsystem 48, for example, a system that manages the exchange of documents for various procedures with the JPO, and changes in the progress of the procedure in the filed application. This is a means for acquiring information on the progress (update information of progress data) and updating the progress data on the case registered in the case database 43.

  The case database 43 is a database in which data related to cases including progress data is accumulated.

  The alerting condition master 44 is a setting file in which alerting conditions relating to changes in the procedure progress status of application items are described. In other words, the alert condition master 44 defines what kind of change occurs as a timing for alerting among various changes in the procedure progress status of the application case. For example, “a reference to notify the reason for refusal occurs”, “an amendment occurs”, “an application is withdrawn”, and the like are defined as conditions for alerting.

  The alert determination unit 45 is a means for generating an alert file 49 describing alert words when a change in the procedure progress status of the application case matches the alert condition of the alert condition master 44.

  For example, the front page generation unit 46 is a unit that reads the attention file 49 generated by the attention determination unit 45 in response to a login request from the client 50 and generates a front page that is an attention screen.

  The data transmission unit 47 is a means for transmitting, for example, a front page including the contents of the alert file 49 generated by the front page generation unit 46 from the server 40 to the client 50.

  Next, the operation of the intellectual property management system 200 according to the second embodiment will be described.

  FIG. 7 is a flowchart regarding the alerting process in the intellectual property management system 200 of the present embodiment.

  In this intellectual property management system 200, for example, a change in the procedure progress status of an application case occurs from a subsystem 48 that is connected to the JPO and manages the exchange of documents for various procedures with the JPO. Each time, information on the latest procedure progress status of the application case (update information of progress data) is acquired, and the case progress data in the case database 43 is updated based on this information (step S701).

  When the matter progress data in the matter database 43 is updated, the alert determination unit 45 compares the progress data update information of the matter with the alert condition of the alert condition master 44 (step S702), and When the progress data update information matches the alert condition of the alert condition master 44, the alert file 49 is generated (step S703).

  For example, as shown in FIG. 8, the alert file 49 includes an update occurrence date 53 and an update content 54 of the procedure progress status of the application case. The update content 54 described in the alert file 49 is specifically “A notice of reason for refusal was issued in domestic P45678 and a reference occurred.” “A notice of reason for refusal was issued in domestic P82721 and amendment occurred. ”And so on, the user can confirm the contents directly.

  Thereafter, when a login request is sent from the client 50 to the server 40 (step S704), the front page generation unit 46 of the server 40 reads the contents of the alert file 49 as a trigger, and the contents of these alert files 49 Is generated (step S705). The generated front page is transmitted to the client 50 through the network 30 by the data transmission unit 47 and displayed on the display unit 51 of the client 50 (step S706).

  Thereby, the user of the client 50 can confirm the important update contents of the progress status of the matter at every login.

  In addition, the alerting process of the second embodiment can be incorporated into the intellectual property management system together with the alerting process of the first embodiment.

  Next, a third embodiment of the present invention will be described.

  FIG. 9 is a block diagram relating to an alerting process in the intellectual property management system according to the third embodiment.

  The intellectual property management system 300 according to the present embodiment includes a server 60 and a client 70. The server 60 and the client 70 are connected through the network 30.

  The client 70 includes a display unit 71 that displays an inquiry screen and an input screen for various data related to the case and the customer, and an input unit 72 that allows the user to input various data related to the item and the customer on the input screen displayed on the display unit 71. And have.

  The server 60 includes a data receiving unit 61, a case unit alert registration unit 62, a customer unit alert registration unit 63, an item database 64, a customer master database 65, a display screen generation unit 66, and a data transmission unit 67.

  The data receiving unit 61 is a means for receiving, for example, various requests, data relating to cases, alert data for each case, alert data for each customer, and the like transmitted from the client 70.

  The case unit alerting registration unit 62 is a means for registering the alert data for the case unit input from the client 70 in the case database 64.

  The customer unit alert registration unit 63 is a means for registering customer alert data input from the client 70 in the customer master database 65.

  The case database 64 is a database that accumulates information related to cases and alert data for each case.

  The customer master database 65 is a database that stores a customer master including information related to customers and data for alerting customers.

  The display screen generation unit 66 reads the alert data for each case and the alert data for each customer from the matter database 64 and the customer master database 65 in response to an instruction input from the user of the client 70, and generates an alert. A means for generating a data display screen and a data input screen.

  The data transmission unit 67 is a means for transmitting information such as the alert data display screen and the data input screen generated by the display screen generation unit 66 to the client 70 via the network 30.

  Next, the operation of the intellectual property management system 300 of this embodiment will be described.

  FIG. 10 is a diagram showing a case inquiry screen 73 displayed on the display unit 71 of the client 70. As shown in the figure, the case inquiry screen 73 is provided with icons 74, 75, and 76 for alerting. The alert icons 74, 75, and 76 include an alert icon 74 for each project, an alert icon 75 for a special note for each customer, and an alert icon 76 for a black classification for each customer. There is. The icons 74, 75, and 76 can be distinguished from each other by colors such as red, blue, and yellow. These icons 74, 75, and 76 are displayed when there are special matters relating to the case or the customer, and do not appear on the case inquiry screen when there are no special matters. For example, when there is a special mention item only for a case, only the icon 74 for alerting for each case appears on the screen.

  FIG. 11 is a flowchart of the alerting process regarding the special notes for each case.

  In the case inquiry screen 73 displayed on the display unit 71 of the client 70 in FIG. When the special item button 77 is selected by the user using the input unit 72, the information is transmitted as a special item input screen request from the client 70 to the server 60 through the network 30 (step S1101). The server 60 receives the request for the special item input screen at the data receiving unit 61 and is given from the data receiving unit 61 to the display screen generating unit 66. In response to the request for the special note entry screen, the display screen generation unit 66 extracts the special note data for the case currently being inquired from the case database 64 (step S1101), and the special note inquiry including the special note data is performed. An input screen is generated and output to the client 70 through the data transmission unit 67 (step S1103).

  The client 70 displays the special note inquiry input screen received from the server 60 on the display unit 71 (step S1104). FIG. 12 shows an example of this special item inquiry input screen 78. As shown in the figure, the special item inquiry input screen 78 can display a plurality of special items for one item. In this example, registered special note data is already displayed in the text box 79 as the special note item 1. The text box 80 of the remarks 2 is still blank. Here, the user inputs new special item data into the text box 80 of the special item 2 using the input unit 72 as necessary. In order to validate the data of the special note entered in the text box 80 of the special note 2, the user checks the check box 81 of “display for alert” provided below the text box 80. Enter it. When a registration button (not shown) provided on the special mention inquiry input screen 78 is selected by the user's operation of the input unit 72, the content newly inputted on the special mention inquiry input screen 78 is transmitted to the server 60 (step S1105). ), The server 60 receives this at the data receiving unit 61 and transfers it to the case unit alerting registration unit 62.

  The case unit alerting registration unit 62 registers the data of the special note newly input on the special note inquiry screen in the case database 64 (step S1106). At this time, if the “display for alert” check box 81 is checked, it is registered as a special remark item that is valid as an alert target, and when generating a case inquiry screen 73 for this case, it is used for alerting for each case. This is reflected in the determination of the display / non-display of the icon 74.

  FIG. 13 is a flowchart of processing related to alerting special notes for each customer.

  FIG. 14 shows an example of a customer master inquiry screen 82. The customer master inquiry screen 82 is provided with a special note button 83. When the special item button 83 is selected by the user using the input unit 72, the information is received as a special item list introduction screen request from the client 70 through the network 30 by the data receiving unit 61 of the server 60 (step S1301). ). The server 60 receives the special item list introduction screen request at the data receiving unit 61 and is given from the data receiving unit 61 to the display screen generating unit 66. In response to this, the display screen generation unit 66 extracts information on the list of special items about the customer currently inquired from the customer master database 65 (step S1302), and makes a special item list inquiry including the list of special items. A screen is generated and output to the client 70 through the data transmission unit 67 (step S1303).

  The client 70 displays the special item list inquiry screen received from the server 60 on the display unit 71 (step S1304). FIG. 15 shows an example of the special item list inquiry screen 84. As shown in the figure, the special item list inquiry screen 84 displays, as information for each special item, a special item management code 86 uniquely assigned to the special item data relating to the customer, and the input order of each special item. A history code 87 or the like is displayed. Here, a link for calling a display screen for a special note item corresponding to the special note item management code 86 is set at the display position of each special item item management code 86, and the user can set any special special item item management code 86. This information is sent to the server 60 by performing the click operation at the position of, and the information on the display screen of the special note linked to the special note management code 86 is sent from the server 60 to the client 70. Are displayed on the display unit 71. As a result, the user of the client 70 can refer to the data of the special notes related to the customer.

  In addition, the special item list inquiry screen 84 is provided with a button 85 for new input of special item data. When the new input button 85 is selected by the user using the input unit 72, Information is transmitted from the client 70 to the server 60 through the network 30 as a special item input screen request (step S1305). Upon receiving the special item input screen request, the server 60 generates a special item input screen and outputs it to the client 70 through the data transmission unit 67 (step S1306).

  Upon receiving this special note entry screen, the client 70 displays it on the display unit 71 (step S1307). FIG. 16 shows an example of the special note entry screen 88. On the special note entry screen 88, a text box 89 for inputting a special note management code, a text box 90 for inputting a history code, a text box 91 for inputting a delivery destination code, a text box 92 for inputting a special note, and “ A check box 93 for “display for alerting” and the like are provided. The user uses the input unit 72 to input necessary data in the check boxes 89, 90, 91, 92 on the special note entry screen 88. In order to validate the special note entered on the special note entry screen 88, the user inputs a check in the “display for alert” check box 93.

  When a registration button (not shown) provided on the special note entry screen 88 is selected by an operation of the input unit 72 by the user, the contents inputted on the special note entry screen 88 are transmitted to the server 60, and the server 60 The data is received by the data receiving unit 61 and delivered to the customer unit alerting registration unit 63. The customer unit alert registration unit 63 registers each data input on the special note input screen 88 in the customer master database 65. At this time, if the check box 93 of “display for alerting” is checked, it is registered as a special note effective as a target for alerting, and then when a case inquiry screen 73 is generated, a note regarding a special note for each customer This is reflected in the determination of display / non-display of the icon 75 for arousing.

  FIG. 17 is a flowchart of processing related to alerting regarding black check for each customer.

  As shown in FIG. 18, the customer master inquiry screen 94 is provided with a check box 95 for black classification. When the user of the client 70 uses the input unit 72 to check the check box 95 of the black section, and the registration button provided on the customer master inquiry screen 94 is selected by the operation of the input unit 72 by the user, The contents of the input to the black category check box 95 are transmitted to the server 60 (step S1701), and the server 60 receives this at the data receiving unit 61 and transfers it to the customer unit alert registration unit 63. The customer unit alert registration unit 63 registers information in the customer master database 65 so that the target customer is a customer in the black category (step S1702). This black section information is reflected in the decision to display / hide the alert icon 76 regarding the black section for each customer when the case inquiry screen 73 is generated next. When customer data set with a black category is selected from the customer master, information such as a window in which alert information indicating that the customer is a customer in the black category is displayed on the display unit 71 of the client 70. The

  As described above, according to the present embodiment, on the case inquiry screen 73, the icon 74 for calling attention for each case, the icon 75 for calling attention regarding the special notes for each customer, and the warning regarding the black classification for each customer. The icon 76 can be displayed to alert the user that there are important special notes. In addition, you can enter special item data for each project and special item data for each customer in a graphical environment, and you can easily call and view registered special item data by clicking the button with a mouse. Can do. Further, the alerting process of the third embodiment can be incorporated into the intellectual property management system together with the alerting process of the first embodiment or the alerting process of the second embodiment.

  Next, a fourth embodiment of the present invention will be described.

  In this embodiment, for example, as shown in FIG. 19, in order to call the user's attention to items 131 and 132 that hold information in the case inquiry screen 73, the items that hold the information are Highlighting other items that do not hold information in an identifiable manner, or indicating that the contractual rights holder and the procedural rights holder do not match as a group (Gr) company alarm 133 It is a thing. As a method for displaying an item in an identifiable manner, there are a method for changing the display color, shape, and font type of the item, a method for displaying a text link of the item, and the like. Note that the displayed items include buttons, tabs, icons, and the like. The display form of the group (Gr) company alarm 133 is the same.

  The items to be determined whether or not the information is held may be all items, but it is better to limit the items to which information can be generated other than the basic procedure flow. That is, it is important that the user can easily determine the presence or absence of information other than the basic procedure flow. If all items are targeted, the number of highlighted items may increase so much that the significance of the items may be lost.

  Items that may generate information other than the basic procedure flow include, for example, related information, memos, referees, and oppositions. The related information is information related to an application related to the inquiry item on the item inquiry screen 73. The memo is memo data that is handled other than the above-mentioned special notes.

  The group (Gr) company alarm is an alarm display indicating that the right holder in the contract of the inquiry item on the item inquiry screen 73 does not match the right person in the procedure. Here, the contractual right holder is the name of the transferee of the relevant case, and the right holder of the procedure is the name of the applicant who has not completed the right holder change procedure (the name of the applicant on the customer master of the case). The case where the right holder in the contract of the inquiry item and the right holder in the procedure do not match may occur due to the following situation, for example. Assume that there is a company B established by splitting from company A and company A. If Company A, the applicant of Case X, transfers the case to Company B, and Company B becomes the contractual holder, and has not made the name change procedure to the Patent Office, Project X will be a transfer project and will be under the jurisdiction of Company B, but Company A will need to perform procedures such as intermediate processing for the JPO. That is, in this case, the contractual right holder is company B, and the procedural right holder is company A, and the display of the group (Gr) company alarm becomes effective due to the mismatch of the right holders. Management of the right holder of such a case is performed by history information described later.

  In the example of FIG. 19, when the items to be alerted are limited to items that can generate information other than the basic procedure flow, the items holding the information are related information and memos. This is an example showing a case where the display of the group (Gr) company alarm is enabled.

  Next, related information registration processing will be described with reference to FIGS. 9, 19, and 20. FIG. 20 is a flowchart regarding registration of related information. As shown in FIG. 19, when a related information item on the case inquiry screen 73 is selected by the user using the input unit 72 (see FIG. 9), a request for the related information input screen is sent to the client 70 (see FIG. 9). To the server 60 (see FIG. 9) through the network 30 (see FIG. 9) (step S1901). The server 60 receives the request for the related information input screen at the data receiving unit 61 (see FIG. 9), and gives the request to the display screen generating unit 66 (see FIG. 9) from the data receiving unit 61. In response to the request for the related information input screen, the display screen generation unit 66 extracts data of related information about the currently inquired case from the case database 64 (see FIG. 9) (step S1902). A related information inquiry input screen including “” is generated and output to the client 70 through the data transmission unit 67 (see FIG. 9) (step S 1903).

  The client 70 displays the related information inquiry input screen received from the server 60 on the display unit 71 (see FIG. 9) (step S1904). FIG. 21 shows an example of the related information inquiry input screen 101. As shown in the figure, the related information inquiry input screen 101 is an area in which information related to an application case having some relation to the case being inquired, for example, related information such as the application country name, four divisions, and the application number is registered. (Text box) is provided. Here, the user inputs related information to each area of the related information inquiry input screen using the input unit 72 as necessary. Thereafter, when a registration button (not shown) provided on the related information inquiry input screen 101 is selected by an operation of the input unit 72 by the user, the content newly input on the related information inquiry input screen 101 is transmitted to the server 60. (Step S1905), the server 60 receives this at the data receiving unit 61 and transfers it to the case unit alerting registration unit 62 (see FIG. 9). The case unit alerting registration unit 62 registers the related information newly input on the related information inquiry input screen 101 in the case database 64 (step S1906).

  Here, registration of related information has been described. Similarly, for registration of memos, referees, and oppositions, a registration screen is displayed on the client 70, and necessary information is input there. It may be sent to the server 60 and registered in the matter database 64.

  Next, the registration of the history information will be described. FIG. 22 is a flowchart relating to registration of history information.

  In the client 70, when the history information button 101 is selected by the user using the input unit 72 on the customer master inquiry screen 82 shown in FIG. 14, a request for the history information inquiry screen is sent to the server 60 (step S2001). ). Upon receiving the request for the history information inquiry screen, the server 60 extracts the history information of the customer (target customer) inquired on the customer master inquiry screen 82 from the customer master 65 (step S2002). A history information inquiry screen for the target customer is generated and transmitted to the client 70 (step S2003).

  The client 70 displays the target customer history information inquiry screen received from the server 60 on the display unit 71 (step S2004). FIG. 23 shows an example of the history information inquiry screen 110. As shown in the figure, a registration date and history information are displayed on the history information inquiry screen 110. Examples of the history information include a company merger and a company split. The history information inquiry screen 110 is provided with a new input button 111 for history information. When this new history information input button 111 is selected by the user using the input unit 72, the client 70 sends a new history information input screen request to the server 60 (step S2005).

  Upon receiving the new history information input screen request, the server 60 generates a history information input screen and responds to the client 70 (step S2006). The client 70 displays the history information input screen received from the server 60 on the display unit 71 (step S2007). FIG. 24 shows an example of a history information input screen 120. As shown in the figure, the history information input screen 120 is provided with input items 122, 123, 124, and 125 for registration date, related customer name, and history information contents (company merger, division, etc.). Furthermore, an input completion button 121 is provided on the history information input screen 120. After the user inputs necessary information for each of the input items 122, 123, 124, and 125 using the input unit 72, an input is performed. When the completion button 121 is selected, the client 70 transmits the history information input to the input items 122, 123, 124, and 125 to the server 60 (step S2008). The server 60 registers the history information received from the client 70 in the customer master 65 (step S2009). This completes the registration of history information.

  Next, in order to call the user's attention to the item holding information in the case inquiry screen 73, the item holding the information is identified with respect to other items not holding the information. A process of highlighting as possible or displaying as an alarm will be described.

  FIG. 25 is a flowchart showing the flow of alert display on the case inquiry screen 73.

  First, in the client 70, a request for calling the matter inquiry screen 73 shown in FIG. 10 is input by the user using the input unit 72, and the request is sent to the server 60 (step S2501). Upon receipt of this request, the server 60 extracts information on each item relating to the target case from the case database 64 (step S2502), and whether information is retained for the item to be alerted (related information, memo, etc.). It is determined whether or not (step S2503). Here, a warning flag is set for an item for which information is held (step S2504).

  Next, the server 60 refers to the customer master 65 to determine whether or not there is history information about the customer of the target case (step S2505). Based on the determination, it is determined whether or not the contractual right holder matches the procedural right holder (step S2506). If the contracted right holder and the procedural right holder do not match, the server 60 sets a group (Gr) company alarm flag (step S2507).

  Thereafter, the server 60 generates warning information for highlighting the corresponding item based on the set warning flag and group (Gr) company alarm flag, and information on the matter inquiry screen 73 is displayed. (Step S2508), and information on the case inquiry screen 73 to which the alert information is added is transmitted to the client 70 (step S2509). When the client 70 receives the information on the case inquiry screen 73 to which the alert information is added, for example, as shown in FIG. 19, the items 70 and 132 holding the information are highlighted and the group (Gr) company alarm is displayed. The case inquiry screen 73 to which 133 is added is displayed on the display unit 71 (step S2510).

  As described above, in the case inquiry screen 73, in order to call the user's attention to the item holding the information, the item holding the information is changed to another item not holding the information. In addition to the basic review flow for a given case, it can be highlighted in an identifiable manner, or a group (Gr) company alarm can be displayed indicating that the contracted rights holder and the procedural rights holder do not match. In addition, it is possible to immediately know the presence or absence of information generated at the same time, and it is possible to reduce the occurrence of oversight of necessary procedural processing for a matter transferred from a procedural right holder to a contract right holder.

  The embodiment according to the present invention has been described above, but the present invention is not limited to the above-described embodiment, and various modifications can be made without departing from the scope of the present invention. .

It is a block diagram regarding the alerting process in the intellectual property management system which concerns on the 1st Embodiment of this invention. It is a figure which shows the outline | summary of the alerting process which concerns on embodiment of FIG. It is a flowchart regarding the operation | movement at the time of acceptance in the alerting process which concerns on embodiment of FIG. It is a flowchart regarding the operation | movement at the time of the customer master change in the alerting process which concerns on embodiment of FIG. It is a flowchart regarding the operation | movement at the time of the application procedure in the alerting process which concerns on embodiment of FIG. It is a block diagram regarding the alerting process in the intellectual property management system which concerns on 2nd Embodiment. It is a flowchart regarding the alerting process which concerns on 2nd Embodiment. It is a figure which shows the specific example of the content of an alerting file. It is a block diagram regarding the alerting process in the intellectual property management system which concerns on 3rd Embodiment. It is a figure which shows the example of the case inquiry screen which concerns on 3rd Embodiment. It is a flowchart of the process regarding alerting of the case unit which concerns on 3rd Embodiment. It is a figure which shows the example of the special feature item inquiry input screen which concerns on 3rd Embodiment. It is a flowchart of the process regarding alerting of the special mention item of the customer unit which concerns on 3rd Embodiment. It is a figure which shows the example of the inquiry screen of the customer master which concerns on 3rd Embodiment. It is a figure which shows the example of the special feature item list inquiry screen which concerns on 3rd Embodiment. It is a figure which shows the example of the special feature item input screen which concerns on 3rd Embodiment. It is a flowchart of the process regarding alerting | calling regarding the black check of the customer unit which concerns on 3rd Embodiment. It is a figure which shows the example of the inquiry screen of the customer master which concerns on 3rd Embodiment. It is a figure which shows the example of the case inquiry screen which concerns on 4th Embodiment. It is a flowchart regarding registration of the relevant information which concerns on 4th Embodiment. It is a figure which shows the example of the related information inquiry input screen which concerns on 4th Embodiment. It is a flowchart regarding registration of the history information which concerns on 4th Embodiment. It is a figure which shows the example of the history information inquiry screen which concerns on 4th Embodiment. It is a figure which shows the example of the history information input screen which concerns on 4th Embodiment. It is a flowchart which shows the flow of the alert display on the case inquiry screen which concerns on 4th Embodiment.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 10 ... Server, 11 ... Data reception part, 12 ... Case data registration part, 13 ... Customer master registration part, 14 ... Case database, 15 ... Customer master database, 17 ... Alerting information addition part, 18 ... Data transmission part, 20 ... Client, 21 ... Display unit, 22 ... Input unit, 30 ... Network, 31 ... Customer code, 32 ... History code, 33 ... Real data about customer, 40 ... Server, 41 ... Data receiving unit, 42 ... Progress data update information Acquisition unit, 43 ... matter database, 44 ... alerting condition master, 45 ... alerting determining unit, 46 ... front page generating unit, 47 ... data transmitting unit, 48 ... subsystem, 49 ... alerting file, 50 ... client, 51 ... Display unit, 52 ... Input unit, 60 ... Server, 61 ... Data receiving unit, 62 ... Project unit alert registration unit, 63 ... Customer Awareness registration part, 64 ... case database, 65 ... customer master database, 66 ... display screen generation part, 67 ... data transmission part, 70 ... client, 71 ... display part, 72 ... input part, 73 ... case inquiry screen, 78 ... Special item inquiry input screen, 100, 200, 300 ... Intellectual property management system.

Claims (9)

A customer master storage unit in which a customer master in which a customer code for identifying a customer, actual data about the customer, and a history code indicating a history of changes in the actual data are stored as customer-related data;
A matter database that is selected from the customer master stored in the customer master storage unit together with data related to the customer related to the matter,
The customer-related data stored in the case database and the customer-related data described in the customer master are compared with each other having a common customer code. An intellectual property management system comprising: an alerting means for outputting alerting information indicating that there is a difference in data.   The intellectual property management system according to claim 1, wherein the alerting unit is activated when a data inquiry request regarding a matter is generated.   3. The intellectual property management system according to claim 1, wherein the actual data relating to the customer is any one of a customer name, an organization name, and a contact address. A setting file storage unit that stores a setting file in which conditions for calling attention regarding changes in the procedure progress status of an application are stored;
A progress data update information acquisition unit for acquiring information on changes in the procedure progress of the application case;
When a change in the procedure progress status of the application case acquired by the progress data update information acquisition means matches a warning condition described in the setting file, a warning file describing a warning word is generated. An alerting judgment section;
The alerting screen generating unit that generates a screen including the alerting word based on the alerting file generated by the alerting determination unit. Intellectual property management system. An input unit for inputting matter-based alert data or customer-unit alert data, and alert data for storing matter-unit alert data or customer-unit alert data input from the input unit A storage unit;
An instruction input means for inputting an instruction for calling up the data for alerting the project unit or the data for alerting the customer unit;
Further comprising: alert data output means for reading out and outputting the alert data for each case instructed by the instruction input means or the alert data for each customer from the alert data storage unit. The intellectual property management system according to claim 1. As customer-related data, a customer code that identifies a customer, customer-related data, a customer master storage unit that stores a customer master in which a history code indicating a history of changes to this actual data is stored, and data related to a matter, A case database selected from the customer master stored in the customer master storage unit and stored together with data related to the customer related to the case;
The customer-related data stored in the case database and the customer-related data described in the customer master are compared with each other having a common customer code. A method for alerting an intellectual property management system, characterized by outputting alert information indicating that there is a difference in data. Computer
A customer master storage unit in which a customer master in which a customer code for identifying a customer, actual data about the customer, and a history code indicating a history of changes in the actual data are stored as customer-related data;
Data relating to the matter selected from the customer master stored in the customer master storage unit, the matter database stored together with the data relating to the customer relating to the matter, data relating to the customer accumulated in the matter database, Compares data related to customers described in the customer master with those having a common customer code, and outputs warning information that there is a difference in actual data related to the customer when the history codes do not match A program characterized by functioning as an alerting means.   The data related to the matter stored in the matter database is composed of a plurality of items of data, and the alerting means refers to the matter database to determine the item holding the data, and the alerting information for this item is displayed. 2. The intellectual property management system according to claim 1, wherein the intellectual property management system is output.   It is possible to register the customer history information in the customer master storage unit, and the alerting means is based on the customer history information, and the agreement right person / procedure right person / The intellectual property management system according to claim 1, wherein a mismatch information is determined, and alert information indicating this is output in the case of a mismatch.

Images