Matching system, computing device, and method

Abstract

A matching system (1) for providing cases that match each of a plurality of groups including companies, said matching system (1) comprising a plurality of user devices (500) and a computing device (100) that communicates with each of the plurality of user devices (500) and can access a database (120), wherein: the plurality of user devices (500) include first user devices operated by users belonging to a first group; the database (120) registers group information capable of identifying each of the plurality of groups, a plurality of sets of case information, and prohibition information capable of identifying case information among the plurality of sets of case information that is prohibited from being associated with the users belonging to the first group; the computing device (100) associates one or more sets of case information among the plurality of sets of case information with the users belonging to the first group and distributes the one or more sets of case information to the first user devices on the basis of the association; and the computing device (100) associates case information that does not include the case information identified by the prohibition information with the users belonging to the first group.

Description

Matching system, computing device, and method

[0001] The present disclosure relates to a matching system, a computing device, and a method.

[0002] Advertising techniques that display advertisements that are estimated to match a user's preferences on the screen of a web page being viewed by the user are generally known. In such advertising techniques, the user's preferences are inferred from various data, and product and service information corresponding to the inference results is provided to the user as advertisements.

[0003] Patent Document 1 describes a method for determining the content of an advertisement by utilizing rules set based on personal information, and a method for determining the content of an advertisement by utilizing rules set based on the hypothesis that people with similar interests and preferences have similar behavioral characteristics.

[0004] Japanese Patent Application Laid-Open No. 2004-021810

[0005] By connecting a wide variety of groups of companies and the like through a network, it is possible to build a platform for the purpose of sharing resources, providing information, etc. By participating in such a platform as a user, companies and the like can enjoy benefits that cannot be obtained by a single company alone, according to the purpose of the platform.

[0006] Companies, etc. can also use the platform to provide project information related to their business to other companies that are deemed to have a high advertising effect. The more users participate in the platform and the larger the platform becomes, the greater the advertising effect is expected to be. This allows companies, etc. to effectively provide various project information to many other companies, etc. that are deemed to have a high interest in their company's projects among the users of the platform.

[0007] However, there is a possibility that other companies interested in your company's projects may include your company's competitors. This possibility increases as the scale of the platform grows. It is not desirable to actively provide your company's project information to competitors, and in fact, you should not provide your company's project information to competitors.

[0008] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to enable a group of companies or the like to effectively provide project information to other groups, while restricting the provision of project information to competing groups.

[0009] A matching system according to a first aspect of the present disclosure is a matching system that provides project information matching each of a plurality of groups including companies, and includes a plurality of user devices and a computing device that communicates with each of the plurality of user devices and can access a database, wherein the plurality of user devices include a first user device operated by a user belonging to a first group, and the database registers group information that can identify each of the plurality of groups, a plurality of project information, and prohibition information that can identify project information that prohibits associating the plurality of project information with a user belonging to the first group, and the computing device associates one or more of the plurality of project information with a user belonging to the first group and delivers the one or more project information to the first user device based on the association, and the computing device associates the project information with a user belonging to the first group, excluding the project information identified by the prohibition information.

[0010] A computing device according to a second aspect of the present disclosure is a computing device included in a matching system that provides project information matching each of a plurality of groups including companies, and is equipped with a communication interface that communicates with a plurality of user devices including a first user device operated by a user belonging to a first group, and a processor that accesses a database, in which group information capable of identifying each of the plurality of groups, a plurality of project information, and prohibition information capable of identifying project information among the plurality of project information that prohibits it from being associated with a user belonging to the first group, the processor associates one or more of the plurality of project information with a user belonging to the first group and delivers the one or more project information to the first user device, and the processor excludes the project information identified by the prohibition information and associates the project information with the user belonging to the first group.

[0011] A method according to a third aspect of the present disclosure is a method for providing project information that matches each of a plurality of groups including a company, and includes the steps of communicating with a plurality of user devices including a first user device operated by a user belonging to a first group, accessing a database in which group information capable of identifying each of the plurality of groups, a plurality of project information, and prohibition information capable of identifying project information that prohibits associating the plurality of project information with a user belonging to the first group is registered, associating one or more of the plurality of project information with a user belonging to the first group and delivering the one or more project information to the first user device, and excluding the project information identified by the prohibition information and associating the project information with a user belonging to the first group.

[0012] According to the present disclosure, it is possible to effectively provide project information from a group of companies or the like to other groups, while restricting the provision of project information to competing groups.

[0013] 1 is a block diagram showing an overview of a matching system. FIG. 1 is a block diagram showing the configurations of a sharing server, a recruiter device, and an applicant device. FIG. 2 is a block diagram showing the configurations of a sharing server, a recruiter device, and an applicant device. FIG. 3 is a block diagram showing an example of a company database. FIG. 4 is a block diagram showing an example of a member database. FIG. 5 is a block diagram showing an example of a community database. FIG. 6 is a block diagram showing an example of a job posting database. FIG. 7 is a block diagram showing an example of a side job database. FIG. 8 is a block diagram showing an example of an evaluation input database. FIG. 9 is a block diagram showing an example of an evaluation summary database. FIG. 10 is a block diagram explaining the functions of the sharing server, the recruiter device, and the applicant device. FIG. 11 is a block diagram explaining the functions of the sharing server, the recruiter device, and the applicant device. FIG. 12 is a block diagram explaining the functions of the sharing server, the recruiter device, and the applicant device. FIG. 13 is a block diagram explaining the functions of the applicant device. FIG. 14 is a block diagram explaining the procedure for registering a job posting in the job posting database. FIG. 15 is a block diagram explaining the procedure for searching for a job posting from the database. FIG. 16 is a block diagram explaining the procedure for registering plans and results of a side job in the database. FIG. 17 is a block diagram explaining the procedure for registering an evaluation of an applicant in the database. FIG. 18 is a block diagram explaining the procedure for registering an evaluation of a recruiter in the database. FIG. 19 is a block diagram explaining the procedure for displaying evaluations of an applicant and search results of members on a display. FIG. 19 is a block diagram explaining the procedure for displaying evaluations of a recruiter and search results of members on a display. 1 is a diagram for explaining the viewable range of the evaluation summary database. FIG. 2 is a diagram showing an example in which the disclosure range is set according to the disclosure level. FIG. 3 is a diagram showing a screen displayed on the applicant device of a manager (an applicant's boss) when the manager checks the side job status of his or her subordinates. FIG. 4 is a diagram showing details of the job contents contained in the job recruitment database. FIG. 5 is a diagram showing an overview of the job information distribution function provided in the matching system. FIG. 6 is a diagram showing an example of an in-house terminology database. FIG. 7 is a diagram showing an example of a profile database and an action history database. FIG. 8 is a diagram showing an example of a job introduction database. FIG. 9 is a diagram showing an example of a priority database. FIG. 10 is a flowchart showing the processing steps related to the job information distribution function of the matching system. FIG. 11 is a flowchart showing the processing steps of a job information registration unit. FIG. 12 is a flowchart showing the processing steps of a user information acquisition unit.1 is a flowchart showing the processing steps of a content-based algorithm. 2 is a flowchart showing the processing steps of a collaboration-based algorithm. 3 is a flowchart showing the processing steps of a decision algorithm. 4 is a flowchart showing the processing steps of a job information acquisition unit. 5 is a flowchart showing the processing steps of a display unit. 6 is a flowchart showing the processing steps of a display effect feedback unit. 7 is a flowchart showing the processing steps of a learning unit. 8 is a flowchart showing the processing steps related to the indexing function of the matching system. 9 is a flowchart showing the processing steps of an internal company terminology registration unit. 10 is a flowchart showing the processing steps of a job registration unit. 11 is a flowchart showing the processing steps for displaying the meaning of an internal company terminology on a screen in accordance with an applicant's operation. 12 is a diagram for explaining the functions of a sharing server, a recruiter device, and an applicant device according to Modification 1. 13 is a diagram showing an example of a member database according to Modification 1. 14 is a flowchart showing the processing steps of a counter offer member search process according to Modification 1. 15 is a block diagram showing the configurations of a sharing server, a recruiter device, and an applicant device according to Modification 2. 16 is a diagram showing an example of a member group database according to Modification 2. 17 is a diagram showing an example of a recruiter device and an applicant device according to Modification 2. 18 is a diagram showing the functions of a sharing server, a recruiter device, and an applicant device according to Modification 2. 19 is a diagram showing the procedure for registering a recruit in the recruit database according to Modification 2. 20 is a diagram showing the configuration of a matching system according to Modification 3. 21 is a diagram showing an example (Modification 4) of applying Kerberos authentication to a matching system.

[0014] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings. In the drawings, the same or corresponding parts are designated by the same reference numerals, and description thereof will not be repeated.

[0015] [Background for Proposing Matching System 1] Fig. 1 is a block diagram showing an outline of a matching system 1 according to this embodiment. First, the background for proposing matching system 1 in this embodiment will be described.

[0016] The matching system 1 is used, for example, in crowdsourcing between businesses. Crowdsourcing is generally a process of soliciting contributions from an unspecified number of people to obtain needed services, ideas, or content.

[0017] Many companies are encouraging employees to have side jobs in order to make effective use of their human resources. By using crowdsourcing between companies, the capabilities of employees can be utilized.

[0018] However, if general crowdsourcing methods are applied directly between companies, the following problems may arise.

[0019] [Potential for confidential information to be leaked] General crowdsourcing methods do not take into consideration the relationship between the client company and the recipient company, so adopting crowdsourcing involves both corporate and personal risks. For example, there is a risk that confidential information may be leaked to a rival company through an employee's side job. With traditional crowdsourcing methods, managers cannot verify that employees are not taking on projects from competitors as side jobs.

[0020] [Possibility of overwork] If a company allows its employees to have side jobs, there is a risk that their working hours will become excessively long. To eliminate the risk of overwork, companies could set an upper limit on overtime hours, including for their main job and side job. However, as long as employees are free to take on side jobs, it will be difficult for companies to control the amount of time employees spend on side jobs. As a result, there is a risk that employees will end up overworked.

[0021] [Possibility that the results of side jobs may not be properly evaluated] Conventionally, there are crowdsourcing systems that request clients to evaluate contractors. If the appropriate evaluations made by the client are shared on the crowdsourcing system, those seeking contractors for the work can refer to those evaluations and select highly capable individuals from among the many people who wish to accept the work.

[0022] However, a client of a certain company may be so concerned about the contractors of other companies being evaluated that they enter a higher rating into the system than they should. Also, a client of a certain company may avoid giving a low rating to a contractor of another company, fearing that this could worsen the relationship between the companies. Furthermore, a client may not see any benefit in providing a rating and enter a rating that is far from their true rating into the system. Considering these possibilities, the reliability of the ratings provided by the system may be reduced. In this case, even if the ratings of contractors are shared, the client of the work cannot use the ratings as reference data when selecting a contractor.

[0023] [Possibility of not obtaining accurate information about the recruiter] In a crowdsourcing system like the one described above, applicants who wish to apply for a job will likely select a job that satisfies them, taking into consideration the job content, compensation, etc. However, some recruiters (project owners) may frequently make additional requests outside the scope of the contract or instruct changes to the job content. Applicants will likely want to avoid such recruiters when applying for the job. Conversely, there may also be recruiters who do not cause any problems until the job is completed. Applicants will likely want to apply for a job offered by such recruiters, if possible. Therefore, it is desirable for evaluations of not only applicants (contractors) but also recruiters (clients) to be widely shared in the crowdsourcing system.

[0024] If appropriate evaluations of job seekers are shared on a crowdsourcing system, people who are planning to apply for work can use the evaluations as a reference and select a job that satisfies them from among the many available jobs, taking into account the job seeker's past transaction history, etc.

[0025] However, when building an evaluation system that allows evaluation of solicitors, similar problems can arise. Specifically, a contractor (applicant) from one company may enter a higher evaluation into the system than they should, out of consideration for the client (recruiter) of another company being evaluated. Furthermore, a contractor (applicant) from one company may avoid rating another company's client (recruiter) low, fearing that this could worsen the relationship between the companies. Furthermore, contractors (applicants) may not see any benefit in providing an evaluation and enter an evaluation that is far from their true evaluation. Considering these possibilities, the reliability of the evaluations provided by the system may be reduced. In this case, even if evaluations of solicitors are shared, applicants cannot use those evaluations as reference data when selecting a solicitor.

[0026] [Special features of having a company as the matching entity] Generally, in order to match talent with jobs across companies, a close relationship, such as a relationship of trust, is required between the companies matching talent and jobs. Therefore, for example, it is extremely difficult to match talent with jobs across companies that have no capital relationship. In addition, large companies such as listed companies are prone to competing with other companies from the perspective of diversified management, etc., and cannibalization occurs between other companies, so they are faced with the unique situation of not being able to match talent with jobs across a large number of companies.

[0027] [Possibility of recommended jobs being distributed to competitors] If a platform that can provide crowdsourcing to companies is built, the platform will grow in size as the number of companies participating in the platform increases. A network that includes a wide variety of companies will be formed on the large platform. Using this network, participating companies could distribute "recommended jobs" to other participating companies, encouraging them to apply as applicants. In this case, it is desirable to add a "job information distribution function" to the platform that can distribute recommended jobs based on the results of analyzing user preferences. By adding a "job information distribution function" to the platform, the owner of a job (recruiter) can distribute their company's job to other companies that have a high interest in their job.

[0028] However, there is a possibility that other companies interested in your company's projects may include your competitors. This possibility increases as the scale of the platform grows. It is not advisable to actively provide your company's projects to competitors, as the projects may contain your company's technical information.

[0029] A typical advertising distribution system has a mechanism for determining the destination of advertisements based on the user's attributes and behavior. It is conceivable to apply such a mechanism to exclude competing companies from the destinations of recommended offers. However, in widely used network platforms such as SNS (Social Networking Service), it cannot be denied that users may falsify their attributes, and the estimation results are not always correct.

[0030] If the estimation result is incorrect, there is a risk that a project that should not be shown to competitors will be distributed to competitors. For this reason, it is not desirable to determine whether a user belongs to a competitor based on the user's attributes and behavior obtained from the network.

[0031] [Internal jargon may hinder communication] In some companies, internal jargon specific to that company is widely used. Although internal jargon is understood by people in the company where it is widely used, there is a risk that it may not be understood by people who do not belong to the company where it is widely used. Alternatively, internal jargon may be understood as a term with a specific meaning among people in the company where it is widely used, but may be understood as a term with a different meaning from that specific meaning by people who do not belong to the company where it is widely used.

[0032] There is a possibility that company jargon may be used in the job posting. If the company to which the recruiter belongs is different from the company to which the applicant belongs, the applicant may not correctly understand the meaning of the company jargon used by the recruiter in the job posting. The applicant may apply for the job without correctly understanding the meaning of the company jargon used by the recruiter in the job posting. As a result, there is a risk of work-related problems occurring.

[0033] In-house jargon may be used during meetings between recruiters and applicants. If the recruiter belongs to a different company than the applicant, the applicant may not correctly understand the meaning of the in-house jargon used by the recruiter. Similarly, the recruiter may not correctly understand the meaning of the in-house jargon used by the applicant.

[0034] If the company term used by either the recruiter or the applicant is unfamiliar, the other person can understand the meaning of the term by asking the speaker. However, if the understanding of the meaning of a certain company term differs between the recruiter and the applicant, the meeting will proceed without correcting the misunderstanding between the two parties. This can result in business trouble.

[0035] Terms similar to in-house jargon can be used with unique meanings not only in companies but also in non-profit organizations. Whether for-profit or non-profit, an organization may be divided into multiple units, such as departments and sections, and each unit may have its own unique terminology. Such terms may also be prevalent in communities formed by multiple organizations, such as companies. Therefore, when recruiters and applicants belong to different organizations, units, and communities, differences in understanding of terminology can lead to the business-related problems described above.

[0036] In this embodiment, the term "in-house terminology" refers not only to "internal terminology" used in profit-making organizations such as companies and their units, but also to "terms similar to internal terminology" used in non-profit organizations, communities, and their units. In the following, this embodiment will be explained using "internal terminology" for a company as an example of "in-house terminology."

[0037] In this embodiment, a matching system 1, which will be described in detail below, is proposed in order to solve at least one of the above-mentioned various problems that conventional crowdsourcing has.

[0038] [Overall Configuration] The general configuration of the matching system 1 will be described with reference to Fig. 1. The matching system 1 includes a sharing server 100, recruiter devices 200A, 200B, 200C, etc., and applicant devices 300A, 300B, 300C, etc.

[0039] The sharing server 100 provides a matching service to many companies that matches business orders and receipts between companies. Figure 1 shows company A, company B, company C, etc. as examples of companies that use the matching service. Company A, company B, company C, etc. are registered as corporate members of the matching system 1. Employees of company A, company B, company C, etc. who use the matching system 1 are also individually registered as members of the matching system 1.

[0040] The work arranged by the matching system 1 is, for example, temporary work that is expected to be completed within a predetermined period of time. Therefore, a person who accepts a work arranged by the matching system 1 will work in the specific department to which they belong within the company as their main job, and will engage in the work arranged by the matching system 1 as a side job, respectively. Note that in the matching system 1, for example, an applicant from company A can also accept an order for work from company A. Therefore, in the matching system 1, an applicant who belongs to a different department Y of company A is also allowed to accept an order for work from department X of company A.

[0041] Hereinafter, a job for which contractors are being recruited in the matching system 1 may be referred to as a "job being recruited," "job opening," or "job," a person providing a job opening may be referred to as a "recruiter" or "job owner," and a person applying to receive an order for a job opening may be referred to as an "applicant." Applying for a job opening may be referred to as an "application for a job being recruited," "application for a job opening," or "application for a job."

[0042] An applicant who accepts a job offer is referred to as the "contractor," and a recruiter who places an order with a contractor is referred to as the "orderer." However, in the following, the "contractor" may be referred to as the "applicant," and the "orderer" may be referred to as the "recruiter (job owner)."

[0043] The sharing server 100 has a database 120 necessary for the matching service. The database 120 includes various databases in which information necessary for providing the matching service is registered. For example, the database 120 registers information about members and recruitment operations. The sharing server 100 is managed and operated by a company separate from the companies that use the matching service. Any of the companies that use the matching service may manage and operate the sharing server 100.

[0044] The recruiter device 200A is operated by an administrator of company A. The recruiter device 200B is operated by an administrator of company B. The recruiter device 200C is operated by an administrator of company C. Hereinafter, the recruiter devices 200A, 200B, 200C, etc. may be collectively referred to as "recruiter devices 200."

[0045] Applicant device 300A is operated by an applicant from company A. Applicant device 300B is operated by an applicant from company B. Applicant device 300C is operated by an applicant from company C. Hereinafter, applicant devices 300A, 300B, 300C, etc. may be collectively referred to as "applicant devices 300." Although FIG. 1 shows two applicants for each company, the number of applicants is not limited to this. There may be more applicants for each company, or a company may have only one applicant. Sharing server 100 may also accept applicants who do not belong to a company, such as freelancers.

[0046] In this embodiment, the managers of companies A, B, C, etc. will act as recruiters. Therefore, hereinafter, the managers of each company will be referred to as "recruiters." In this embodiment, when a company manager acts as a recruiter, the device that the manager uses to use the matching service will be referred to as recruiter device 200.

[0047] Company A may have one or more administrators. When company A has administrators, each administrator may be given a recruiter device 200, or one recruiter device 200 may be shared by multiple administrators. The same applies to companies B, C, etc.

[0048] The sharing server 100 and the recruiter device 200 are configured to be able to communicate with each other via the Internet 50, which is an example of a communication network. The sharing server 100 and the applicant device 300 are configured to be able to communicate with each other via the Internet 50.

[0049] The sharing server 100 requires sign-in with input of a member ID and password when accepting access from the recruiter device 200. Similarly, the sharing server 100 requires sign-in with input of a member ID and password when accepting access from the applicant device 300. The sharing server 100 identifies each recruiter and applicant by the member ID notified at the time of sign-in.

[0050] The recruiter device 200 accepts various operations by the recruiter. For example, the recruiter device 200 accepts an operation to input a recruitment case (requested work), an operation to input an evaluation of a contractor who has completed the work, an operation to search for a member of the matching service, and the like.

[0051] The recruiter device 200 communicates with the sharing server 100 in response to each operation on the recruiter device 200. The sharing server 100 registers a recruitment request (requested work) in the database 120 in response to an operation to input the recruitment request, registers an evaluation of the target applicant (contractor) in the database 120 in response to an operation to input an evaluation, and provides member information to the recruiter device 200 in response to an operation to search for members.

[0052] The applicant device 300 accepts various operations by the applicant, such as an operation to search for a job offer, an operation to apply for a job offer, an operation to input work results, and an operation to input an evaluation of the recruiter (orderer).

[0053] The applicant device 300 communicates with the sharing server 100 in response to each operation on the applicant device 300. The sharing server 100 provides the applicant device 300 with appropriate job postings in response to an operation to search for job postings, issues a notice of acceptance or rejection to the applicant device 300 in response to an operation to apply for a job posting, registers the job postings in the database 120 in response to an operation to input job postings, and registers an evaluation of the target recruiter (orderer) in the database 120 in response to an operation to input an evaluation.

[0054] As described above, the matching system 1 includes an evaluation system that evaluates applicants (contractors) and recruiters (orderers) for work, and a recruitment system that recruits contractors for work.

[0055] A recruiter belonging to a certain department of company A can employ an applicant belonging to another department of company A as a contractor for a job by using the matching system 1. A recruiter belonging to company A can employ an applicant belonging to company B as a contractor for a job by using the matching system 1.

[0056] A recruiter can also act as an applicant for a job that another recruiter is recruiting for. In that case, the recruiter device 200 functions as the applicant device 300. Of course, an applicant can also act as a recruiter. In that case, the applicant device 300 functions as the recruiter device 200.

[0057] Members who use the matching system 1 access the sharing server 100 as recruiters or applicants. Hereinafter, members of the matching system 1 may be referred to as "users." Hereinafter, the recruiter device 200 and applicant device 300 operated by the members may be collectively referred to as "user device 500." FIG. 1 shows the user device 500.

[0058] A recruiter (project owner) uses a user device 500 to upload a project for recruiting applicants to the sharing server 100. The sharing server 100 selects users who are likely to be interested in the content of the project and distributes recommended projects to the selected users. In this way, the sharing server 100 has the function of distributing recommended projects by utilizing a huge platform built with the participation of many companies. The database 120 of the sharing server 100 stores data that can identify competitive relationships between companies. By using this data, the sharing server 100 prevents the project owner's project from being distributed to competitors.

[0059] 1 illustrates a screen 250 displayed on the recruiter device 200 and a screen 350 displayed on the applicant device 300. A user using the matching system 1 as an applicant looks at a list of recruiting jobs 351 displayed on the screen 350 and selects a job to apply for. At this time, recommended jobs 352 targeting the user are displayed on the screen 350. The user can decide which job to apply for while referring to the recommended jobs 352.

[0060] Such recommended jobs are also provided to a user who is using the matching system 1 as a recruiter. The user who is using the matching system 1 as a recruiter looks at the applicant list 251 displayed on the screen 250 and decides on an applicant to hire as a contractor. At this time, recommended jobs 352 targeting the user are displayed on the screen 250. The user, for example, decides on applicants for his or her own job from the perspective of a recruiter. The user can then consider the recommended jobs 252 displayed on the screen 250 from the perspective of an applicant, not a recruiter.

[0061] When a user accesses the sharing server 100 in the role of a recruiter, the user can also display the applicant's profile on the user device 500. The user uses the user device 500 to check the applicant's work history, etc. Alternatively, the user device 500 displays the job recruitment requirements. The user (applicant) looks at the screen 552 of the user device 500 to check the details of the job. The user (recruiter) looks at the screen 552 to check the applicant's work history, etc. Alternatively, the screen 552 displays reports on ongoing jobs, instructions to change part of the request content, instructions to add to the request content, etc. The user checks the content displayed on the screen 552 and performs necessary processing, such as replying to the other party with the necessary information, using the user device 500.

[0062] Information such as the job requirements, work history, work reports, and instructions displayed on screen 552 may contain company terminology. If the company to which the user viewing screen 552 belongs is different from the company to which the user providing that information belongs, the user viewing screen 552 may not be able to correctly understand the company terminology.

[0063] Therefore, the matching system 1 registers each company's internal terms and their meanings in the database 21. The matching system 1 generates an index of internal terms from texts such as job descriptions used by users, and links the index to the internal terms registered in the database 21. In this way, the matching system 1 has an indexing function.

[0064] When an in-house term is included in a sentence displayed on screen 552, user device 500 displays the in-house term in a different display mode from other terms. This allows the user to understand that the term is an in-house term. Furthermore, user device 500 displays the intended meaning of the in-house term on screen 552 in response to a user operation (for example, a click on the in-house term).

[0065] For example, screen 552 shown in FIG. 1 displays "DX" as an example of an internal company term. "DX" is underlined to indicate that it is an internal company term. The user clicks on "DX." A window explaining the meaning of the term "DX" is then displayed on screen 552. DX is an abbreviation for "Digital Transformation" and generally refers to transformation using digital technology. However, some companies may use "DX" as an internal company term to mean the creation of some kind of new value, regardless of whether digital technology is used. In such cases, the meaning corresponding to the internal company term is explained in the window on screen 552. This allows the user to correctly understand the meaning of "DX" intended by the other party.

[0066] FIG. 2 is a block diagram showing the configurations of the sharing server 100, the recruiter device 200, and the applicant device 300.

[0067] [Configuration of Sharing Server 100 ] The sharing server 100 includes a processor 101 , a memory 102 , a storage 103 , and a communication interface 104 .

[0068] The memory 102 may include a random access memory (RAM), a read only memory (ROM), a flash memory, or any other suitable memory system. The memory 102 stores programs required for the arithmetic processing of the processor 101, temporary data calculated in the arithmetic processing, and the like.

[0069] The storage 103 is configured with a hard disk drive, a solid state drive, etc. A database 120 is stored in the storage 103. The database 120 includes multiple types of databases. The multiple types of databases include a company database (company DB) 121, a member database (member DB) 122, a community database (community DB) 123, a job posting database (job posting DB) 124, a side job database (side job DB) 125, an evaluation input database (evaluation input) 126, an evaluation summary database (evaluation summary DB) 127, and many other databases.

[0070] Some of these multiple types of databases may be stored in storage provided separately from the sharing server 100. For example, the sharing server 100 may be connected to a cloud service separate from the sharing server 100, and some of the multiple types of databases shown in Fig. 2 may be stored on that cloud. In this case, the sharing server 100 can access the necessary databases by communicating with that cloud via the Internet 50.

[0071] Processor 101 connects to Internet 50 via communication interface 104 in accordance with a program stored in memory 102. Processor 101 connects to Internet 50 and communicates with recruiter device 200 and applicant device 300. Processor 101 accesses database 120 and executes processes such as extracting necessary data, registering new data in database 120, and updating data registered in database 120.

[0072] [Configuration of Recruiter Device 200] The recruiter device 200 includes a processor 201, a memory 202, a communication interface 203, an input / output interface 204, a display 205, and an operation unit 206. The operation unit 206 includes a mouse, a keyboard, and the like.

[0073] The memory 202 may include a random access memory (RAM), a read only memory (ROM), a flash memory, or any other suitable memory system. The memory 202 stores programs required for the arithmetic processing of the processor 201, temporary data calculated in the arithmetic processing, and the like.

[0074] The processor 201 connects to the Internet 50 via the communication interface 203 in accordance with a program stored in the memory 202. The processor 201 connects to the Internet 50 and communicates with the sharing server 100. The processor 201 communicates with the sharing server 100 and executes processes such as sending a job offer, displaying information about applicant members on the display 205, placing an order for work with a contractor selected from the applicants, and sending the contents of an evaluation of the contractor entered by the recruiter to the sharing server 100.

[0075] Information input by operating the operation unit 206 is notified to the processor 201 via the input / output interface 204 .

[0076] [Configuration of Applicant Device 300] Applicant device 300 comprises a processor 301, memory 302, a communication interface 303, an input / output interface 304, a display 305, and an operation unit 306. Operation unit 306 is made up of a mouse, a keyboard, and the like.

[0077] The memory 302 may include a random access memory (RAM), a read only memory (ROM), a flash memory, or any other suitable memory system. The memory 302 stores programs required for the arithmetic processing of the processor 301, temporary data calculated in the arithmetic processing, and the like.

[0078] The processor 301 connects to the Internet 50 via the communication interface 303 in accordance with a program stored in the memory 302. The processor 301 connects to the Internet 50 and communicates with the sharing server 100. The processor 301 communicates with the sharing server 100 and executes processes such as applying for a job offer, displaying on the display 305 a notification of whether the applicant has been selected or not for the job offer, transmitting the performance of the work order to the sharing server 100, and transmitting the contents of the evaluation of the recruiter entered by the applicant to the sharing server 100.

[0079] Information input by operating the operation unit 306 is notified to the processor 301 via the input / output interface 304 .

[0080] [Overview of Database 120] Below, an overview of the database 120 will be described. The company database 121 stores information about companies that are members of the matching system 1. The member database 122 stores information about members who use the matching system 1. Many of the members are employees of companies that are members of the matching system 1.

[0081] Members registered in the member database 122 can act as recruiters (orderers) or applicants (recipients of orders) by using the matching system 1. Members may include employees of companies registered in the company database 121 as well as individuals (freelancers) who are not affiliated with a company.

[0082] The community database 123 stores information for identifying companies that belong to a community. A community is formed by agreement between companies. Therefore, multiple communities can be formed depending on how the companies agree. The number of companies that belong to one community can also be set in various ways. Companies that have a community relationship form a relationship of trust within the scope determined by how they agree to form the community. The community database 123 registers information for each community that identifies companies that belong to the community.

[0083] Jobs (jobs) for which contractors are being recruited are registered in the job database 124. Employees of each company can work in their main job in their own department at the company, and at the same time, as members of the matching system 1, can accept orders for jobs from other departments of their own company or jobs from other companies that are registered in the job database 124. In this case, the members accept orders for jobs from other departments of their own company or jobs from other companies as a side job.

[0084] Data indicating the status of a side job is registered for each member in the side job database 125. The data indicating the status of a side job includes information such as side job results and side job plans.

[0085] The evaluation input database 126 stores evaluation information for applicants (contractors) and evaluation information for recruiters (orderers). By using the matching system 1, recruiters (orderers) can evaluate the work performance of applicants (contractors) who have completed a job as an evaluator. By using the matching system 1, applicants (contractors) can evaluate the recruiters (orderers) as an evaluator. Evaluations made by individual evaluators are registered in the evaluation input database 126.

[0086] Evaluation summaries are registered in the evaluation summary database 127. Evaluation summaries are registered for each member in the evaluation summary database 127. The evaluation summaries include a recruiter evaluation summary and an applicant evaluation summary. The recruiter evaluation summary indicates the level of evaluation of the member when he or she behaved as a recruiter (orderer). The applicant evaluation summary indicates the level of evaluation of the member when he or she behaved as an applicant (contract recipient). The recruiter evaluation summary is created based on the applicant's evaluation of the recruiter. The applicant evaluation summary is created based on the recruiter's evaluation of the applicant.

[0087] Members can view the evaluation summaries. Recruiters can view each member's applicant evaluation summaries and select members they deem appropriate as contractors. Applicants can view each member's recruiter evaluation summaries and apply for work from recruiters they deem appropriate.

[0088] [Company Database 121] Figure 3 is a diagram showing an example of the company database 121. In the company database 121, a company ID for identifying the company, the company name, the company address, and the maximum side job time are registered for each company. The maximum side job time is the maximum amount of time an employee is permitted to work as a side job in addition to their main job. The maximum side job time is set for each company. For example, the maximum side job time can be calculated by subtracting the overtime hours at the main job other than the side job. The "prescribed overtime hours" vary from company to company. Note that while Figure 3 shows the maximum side job time in months, it may also be set in weeks. The unit of the maximum side job time may also be set for each company.

[0089] In this embodiment, members are permitted to apply for and accept work from various companies and departments, as long as the side job time limit set by the company to which the member belongs is not exceeded.

[0090] 4 is a diagram showing an example of the member database 122. Various information about members is registered in the member database 122. The various information about members includes a member ID for identifying the member, the ID of the company to which the member belongs, the member name, the member's authority, the department to which the member belongs, and the amount of time allowed for side work.

[0091] The types of member authority include administrator and applicant. A member with administrator authority is given the authority to use the matching system 1 as both a recruiter and an applicant. A member with applicant authority is given the authority to use the matching system 1 as an applicant, but is not given the authority to use the matching system 1 as a recruiter. A department head within a company is given administrator authority to manage the side job status of subordinates within the department. A manager with administrator authority is given the authority to approve applications from their subordinate applicants. Therefore, a manager functions as an approver.

[0092] The side job available time is the remaining time available for a side job. The side job available time is calculated by "side job maximum time - total side job time." If the subject is engaged in multiple side jobs, the total side job time includes the time already spent on those multiple side jobs. The total side job time includes the time already spent on the side job as well as the expected time for the side job. The expected side job time is calculated based on the estimated man-hours registered in the job posting database 124. Figure 4 shows the available side job time on a monthly basis. When an applicant searches for available jobs using the matching system 1, only jobs that can be completed with man-hours within the available side job time are offered as jobs to apply for.

[0093] [Community Database 123] Fig. 5 is a diagram showing an example of the community database 123. Information on communities formed between companies is registered in the community database 123. The community information includes a community ID for identifying the community, a community name, and a list of IDs of companies belonging to the community. Each company can form various communities by agreeing with other companies. A company belonging to a community can change the companies that belong to the community by agreeing with the other companies.

[0094] 6 is a diagram showing an example of the job posting database 124. Information about job postings is registered in the job posting database 124. The job posting information includes a job posting ID for identifying the job posting, the ID of the company to which the recruiter who registered the job posting belongs, a list of non-disclosure company IDs, a disclosure level, a job posting title, an estimated number of man-hours, an estimated period, and job posting details.

[0095] For example, the non-disclosure company ID list registers the IDs of companies that prohibit disclosure of job postings. The disclosure level is set to one of three levels: "our company," "within the community," and "all." If the disclosure level is set to "all," applicants outside the community will also be disclosed.

[0096] The IDs of companies that can view the recruitment requests are shown on the right side of the recruitment request database 124 in Fig. 6. For example, the recruitment request corresponding to request ID = 001 has the disclosure level set to "our company." In this case, only members belonging to the company that registered the recruitment request (company ID = 00A) can view the recruitment request corresponding to request ID = 001.

[0097] Hereinafter, using the case ID, the recruiting cases corresponding to each case ID may be referred to as case 001, case 002, case 003, etc. Similarly, using the community ID, the communities corresponding to each community ID may be referred to as community 01, community 02, community 03, etc., and using the member ID, the members corresponding to each member ID may be referred to as member P1, member P2, member P3, etc. Also, hereinafter, using part of the company ID, the companies corresponding to each company ID may be referred to as company A, company B, company C, etc.

[0098] The disclosure level for case 002 is set to "within the community." According to the community database 123 shown in Fig. 5, the companies that have a community relationship with company A, which registered case 002, are company B and company C. Therefore, as shown in Fig. 6, only members belonging to company A, company B, or company C can view case 002.

[0099] Case 003 has the same registered companies and disclosure level as case 002. However, case 003 has "00B" registered in the non-disclosure company ID list. Therefore, as shown in Figure 6, only members belonging to either company A or company C can view case 003, and members belonging to company B are not authorized to view case 003.

[0100] If the disclosure level of a job posting is set to "all," all members can view the job posting. This is the case for job posting 005 shown in Figure 6. If one or more company IDs are registered in the non-disclosure company ID list for job posting 005, members belonging to the companies with those company IDs will not be authorized to view job posting 005.

[0101] The estimated man-hours and estimated period are used by applicants and the matching system 1 to estimate the time it will take to process a recruitment request.

[0102] The user device 500 may provide the user with a setting screen for setting various disclosure levels. For example, the setting screen may display check boxes for the user to select the targets for disclosing cases by industry, such as "pharmaceuticals," "chemicals," "electrical equipment," "railways and buses," and "food." Furthermore, the setting screen may display the names of companies corresponding to each industry, allowing the user to select the targets for disclosing cases by "industry" and "company."

[0103] For example, suppose that the companies corresponding to "pharmaceuticals" are Company A, Company B, Company C, and Company D, the companies corresponding to "chemicals" are Company E, Company F, Company G, and Company H, and the companies corresponding to "electrical equipment" are Company I, Company J, Company K, and Company L.

[0104] In this case, the setting screen indicates that the industry of "pharmaceuticals" includes "Company A" to "Company D," and displays check boxes corresponding to "pharmaceuticals," "Company A," "Company B," "Company C," and "Company D." Furthermore, the setting screen indicates that the industry of "chemicals" includes "Company E" to "Company H," and displays check boxes corresponding to "chemicals," "Company E," "Company F," "Company G," and "Company H." Furthermore, the setting screen indicates that the industry of "electrical equipment" includes "Company I" to "Company L," and displays check boxes corresponding to "electrical equipment," "Company I," "Company J," "Company K," and "Company L."

[0105] For example, suppose a user checks the checkboxes corresponding to "pharmaceuticals" and "chemicals" but does not check the checkbox corresponding to "electrical equipment." In this case, the "electrical equipment" industry is excluded from the targets for which projects will be disclosed. Furthermore, suppose that the checkboxes corresponding to Companies A through C belonging to "pharmaceuticals" and Companies E through H belonging to "chemicals" are checked, but the checkbox corresponding to Company D belonging to "pharmaceuticals" is not checked. In this case, Companies A through C belonging to "pharmaceuticals" and Companies E through H belonging to "chemicals" are treated as targets for which projects will be disclosed, but Company D belonging to "pharmaceuticals" is excluded from the targets for which projects will be disclosed.

[0106] [Side Job Database 125] Figure 7 is a diagram showing an example of the side job database 125. Information showing the side job status of members is registered for each side job case in the side job database 125. The information showing the side job status includes the ID of the member engaged in the side job, the case ID, the month (duration of engagement in the side job), planned side job hours, actual side job hours, expected side job hours, and progress rate.

[0107] The planned side job time is the time a member is expected to need to process an order for which the member has already received the order. Members who have received an order for a side job input their planned side job time each month from their own applicant device 300. The input planned side job time is reflected in the side job database 125. For example, the estimated man-hours for case 001 are set to 5 hours per person per month in the recruiting case database 124. This means that the workload per person is 5 hours per month. Usually, members input their planned side job time using the estimated man-hours for the recruiting case as a guide.

[0108] The side job performance time is the time a member has actually worked on an order-received project. In other words, the side job performance time is the time a member has already worked as an actual result. Each time a member works on an order-received project until the project is completed, the member inputs the time spent working on the project at any timing on their own applicant device 300. The cumulative value of the time input on the applicant device 300 is registered in the side job database 125 as the side job performance time for each month.

[0109] The expected side job time is the time estimated to be required for the work of the target project. In other words, the expected side job time is the time estimated as the member's future working hours. The sharing server 100 automatically sets the expected side job time taking into account the planned side job time and the actual side job time. Members may be allowed to input the expected side job time on their own applicant device 300 at any time until the work of the target project is completed. Furthermore, members may be allowed to modify the automatically set expected side job time. It is desirable that the expected side job time be equal to or less than the planned side job time. However, depending on the status of the project, the expected side job time may be longer than the planned side job time. Members engaged in a project may be able to update their expected side job time at any time until the work of the project is completed.

[0110] The progress rate indicates the degree of progress of the side job. The progress rate is input at the discretion of the person engaged in the side job. The progress rate is input, for example, between 0 (%) and 100 (%).

[0111] For example, when a member initially accepts a project, the progress rate is 0%, the actual side job time is 0 hours, and the planned side job time and expected side job time are the same. As the member progresses with the project and inputs the actual side job time and progress rate, the expected side job time changes.

[0112] The side job database 125 shown in Figure 7 shows side job data for member P2 from October 2021 to December 2021. Referring to the side job database 125 shown in Figure 7, it can be seen that member P2 was engaged in project 001 and project 002 between October 2021 and December 2021.

[0113] The side job database 125 stores the following data for October for case 001: planned side job hours = 5, actual side job hours = 10, and expected side job hours = 10. This shows that member P2 worked on case 001 in October beyond the planned side job hours.

[0114] The data for November for Case 002 is registered in side job database 125 as planned side job hours = 10, actual side job hours = 4, and expected side job hours = 8. From this, it can be seen that member P2 worked on Case 002 in November without exceeding the set expected side job hours. The progress rate of 50 indicates that member P2 completed half of the total work for Case 002 in November.

[0115] In the side job database 125, the December data for case 001 shows that planned side job hours = 5 and expected side job hours = 5, but no actual side job hours are registered. Similarly, the December data for case 002 also shows that actual side job hours are not registered. This means that the system is waiting for member P2 to input actual side job hours.

[0116] The sharing server 100 calculates the member's available capacity for additional side jobs using the expected side job time and actual side job time in the side job database 125. If a member is engaged in multiple side jobs, the sharing server 100 calculates the "total expected side job time," which is the sum of the expected side job times corresponding to those multiple side jobs, and the "total actual side job time," which is the sum of the actual side job times corresponding to those multiple side jobs. The sharing server 100 calculates the available capacity for side jobs by calculating "side job upper limit time - (total expected side job time + total actual side job time)." If "total side job time" is defined as "total expected side job time + total actual side job time," the available capacity for side jobs, i.e., "available side job time," is calculated as "side job upper limit time - total side job time." For example, in the side job database 125 shown in FIG. 7, the total expected side job time for member P2 in December, which is the sum of his or her expected side job hours, is 15 hours (5 hours + 10 hours). Additionally, the total number of hours that member P2 worked on a side job in December was zero. If the "side job limit" set by the company to which member P2 belongs is 30 hours, member P2's remaining capacity for a side job (available time for a side job) is calculated to be 15 hours (30 hours - 15 hours).

[0117] Here, we will explain an example of a more specific procedure for calculating the expected side job time. For example, the "expected side job time" may be calculated based on the formula "(man-hour progress rate / progress rate) x planned side job time - actual side job time." Here, the "man-hour progress rate" is calculated by "actual side job time / planned side job time." As already explained, the "progress rate" is a rate entered into the side job database 125 at the discretion of the person engaged in the side job.

[0118] For example, if the planned time for the side job is 10 hours and the actual time for the side job is 2 hours, the man-hour progress rate is calculated as 20%. Here, let's assume the progress rate is 40%. In this case, the expected time for the side job is calculated as "(20% / 40%) x 10 hours - 2 hours" = 3 hours. In other words, according to this calculation result, the expected time for the side job in question is 3 hours.

[0119] [Evaluation Input Database 126] Fig. 8 is a diagram showing an example of the evaluation input database 126. Evaluation information for the person being evaluated is registered in the evaluation input database 126. The evaluation information includes the subject of evaluation, the member ID of the person being evaluated, the member ID of the evaluator, and the evaluation result.

[0120] The evaluation input database 126 includes a recruiter evaluation section 126A and an applicant evaluation section 126B. Evaluation information for recruiters (orderers) is registered in the recruiter evaluation section 126A. Evaluation information for applicants (contractors) is registered in the applicant evaluation section 126B.

[0121] In the recruiter evaluation section 126A, the evaluation target (evaluated person) corresponds to the recruiter (orderer), and the evaluator corresponds to the applicant who applied for the evaluation target's recruitment work and received the order for the work. The recruiter evaluation section 126A registers evaluations of the evaluated person for each evaluator. Figure 8 shows an example in which members P1 and P2, who correspond to the evaluated person, are evaluated by evaluator members. In particular, Figure 8 shows an example in which member P1 is evaluated by each of evaluator members P5, P7, P11, and P12. The evaluation result (evaluation value) is expressed as a numerical value with 10 as the maximum value and 0 as the minimum value.

[0122] In the applicant evaluation section 126B, the evaluation target (evaluee) corresponds to the applicant (contractor) for the job solicitation, and the evaluator corresponds to the recruiter (orderer) of that job. Evaluations of the evaluatee are registered for each evaluator in the applicant evaluation section 126B. Figure 8 shows an example in which member P7, who corresponds to the evaluatee, is evaluated by members P1, P2, and P3, who correspond to the evaluators. Note that, although examples of evaluation results in the applicant evaluation section 126B are omitted in Figure 8, various evaluation results are registered there, just like in the recruiter evaluation section 126A.

[0123] When an applicant (contractor) completes an order for work received from a recruiter (orderer), he / she uses the applicant device 300 to evaluate the recruiter (evaluator), who is also the assessee. The evaluator's evaluation results are registered in the evaluation input database 126. When an applicant receives an order for work from a recruiter with whom he / she has previously received an order, the applicant evaluates the recruiter again. In this case, the average value of the previous evaluation result and the subsequent evaluation result is registered in the evaluation input database 126.

[0124] When an applicant (contractor) completes a task that the recruiter (orderer) has requested of the applicant (contractor), the recruiter (orderer) uses the recruiter device 200 to evaluate the applicant (contractor) as an evaluator. The evaluator's evaluation results are registered in the evaluation input database 126. When a recruiter orders another task from an applicant who has previously requested a task, the recruiter evaluates the applicant again. In this case, the average value of the previous evaluation result and the subsequent evaluation result is registered in the evaluation input database 126.

[0125] Therefore, the evaluation results registered in the evaluation input database 126 reflect the average value of each evaluator's evaluation of the evaluatee. Note that instead of the average value, a weighted average value calculated according to the number of evaluations or a deviation value, etc., may be used. Evaluation results by case ID may also be registered in the evaluation input database 126.

[0126] [Evaluation Summary Database 127] Fig. 9 is a diagram showing an example of the evaluation summary database 127. Department-specific evaluation information for the person being evaluated is registered in the evaluation summary database 127. The evaluation information by organization includes the evaluation target, the member ID of the person being evaluated, the ID of the company to which the person being evaluated belongs, the ID of the company to which the evaluator belongs, the department to which the evaluator belongs, and an evaluation summary.

[0127] The evaluation summary database 127 includes a recruiter evaluation summary section 127A and an applicant evaluation summary section 127B. In the recruiter evaluation summary section 127A, the evaluation target (evaluated person) corresponds to the recruiter (orderer). In the applicant evaluation summary section 127B, the evaluation target (evaluated person) corresponds to the applicant (contractor). In the evaluation summary database 127, evaluation summaries for the evaluation targets are registered by department.

[0128] The evaluation summary is calculated based on the results of the evaluation input database 126. The department category includes each department, such as the "System Department" or the "Planning Department," that belongs to the company, as well as "Overall," which refers to the entire company. The evaluation summary is calculated for each such "department."

[0129] 9 shows an example in which member P1 corresponds to the person being evaluated in the recruiter evaluation summary section 127A. The company ID of the person being evaluated is "00A." Therefore, member P1 belongs to company A. In FIG. 9, data group 1271 represents company B's evaluation of member P1, who acts as a recruiter, and data group 1272 represents company C's evaluation of member P1, who acts as a recruiter.

[0130] Referring to data group 1271, it can be seen that the evaluation of company B is categorized into an evaluation of the entire company, an evaluation of the systems department within company B, and an evaluation of the planning department within company B. The evaluation summary registers the average value of the evaluation corresponding to each categorized category.

[0131] For example, the evaluation summary corresponding to Company B as a whole is registered with the average value of the evaluation results of the members of Company B who evaluated member P1, who acts as a recruiter. In Figure 9, this value is set to "4.75." The evaluation summary corresponding to the System Department is registered with the average value of the evaluation results of the members of Company B who belong to the System Department and who evaluated member P1, who acts as a recruiter. In Figure 9, this value is set to "4.0." The evaluation summary corresponding to the Planning Department is registered with the average value of the evaluation results of the members of Company B who belong to the Planning Department and who evaluated member P1, who acts as a recruiter. In Figure 9, this value is set to "5.0."

[0132] As with data group 1271, the evaluation of company C in data group 1272 is classified into an evaluation of the entire company and an evaluation of each department within company C. Data groups 1271 and 1272 are data that evaluate recruiters. Therefore, the evaluation summaries registered in data groups 1271 and 1272 are recruiter evaluation summaries.

[0133] The recruiter evaluation summary section 127A has been described in detail above. Next, the applicant evaluation summary section 127B will be described. Figure 9 shows an example of the applicant evaluation summary section 127B in which member P7 is the person being evaluated. The company ID of the person being evaluated is "00C". Therefore, member P7 belongs to company C. In the applicant evaluation summary section 127B, evaluations of member P7, who acts as an applicant, are registered by department.

[0134] The applicant evaluation summary section 127B has a similar structure to the recruiter evaluation summary section 127A, except that the evaluation target is the "applicant" rather than the "recruiter." Therefore, the explanation of the applicant evaluation summary section 127B will be replaced by the explanation of the recruiter evaluation summary section 127A that has already been given.

[0135] The sharing server 100 identifies the evaluation results of each member using the evaluation input database 126, and identifies the affiliation of each member using the member database 122. The sharing server 100 updates the data in the evaluation summary database 127 based on these identification results.

[0136] 9 shows only members P1 and P7 as evaluatees, other members P2 to P6, member P8, member P9, etc. are also registered as evaluatees in the evaluation summary database 127. The evaluation summary database 127 may include data in which the same member is the subject of evaluation as both a recruiter and an applicant. For example, the evaluation summary database 127 shown in FIG. 9 may register an applicant evaluation summary for member P1 in addition to a recruiter evaluation summary for member P1.

[0137] [Functions of the Sharing Server, Recruiter Device, and Applicant Device] FIGS. 10 to 12 are diagrams for explaining the functions of the sharing server, recruiter device, and applicant device.

[0138] 10 , the sharing server 100 functionally includes a community registration unit 140, a company registration unit 141, a member registration unit 142, a member search unit 143, and a case registration unit 144. These various functions are realized by a processor 101, a memory 102, a storage 103, and a communication interface 104 that the sharing server 100 includes.

[0139] The community registration unit 140 has a function of registering a community in the community database 123. A system administrator who manages the matching system 1 inputs information about the community into the sharing server 100 using an operation unit such as a keyboard (not shown).

[0140] The information about the community includes the community name and information about the companies that belong to the community. The community registration unit 140 registers the community in the community database 123 according to the input by the system administrator (step S1). The community registration unit 140 further has a function of updating the information about the community registered in the community database 123.

[0141] The company registration unit 141 has a function of registering new companies that will join the matching system 1. A system administrator inputs information about the company into the sharing server 100 using an operation unit such as a keyboard.

[0142] The information about the company includes the company name, address, maximum side job hours, etc. The company registration unit 141 registers the company in the company database 121 according to the input by the system administrator (step S2). The company registration unit 141 further has a function to update information about companies that have already been registered.

[0143] The member registration unit 142 has a function of registering (signing up) new members who will join the matching system 1. The member registration unit 142 issues a member ID and a password in response to a request from a person belonging to a company that is a member of the matching system 1. A person who wishes to become a member executes the sign-up process using a personal computer or the like (step S3).

[0144] Specifically, a person wishing to become a member inputs information such as their name, company, and department into a personal computer or the like, and transmits the input information to the sharing server 100. The member registration unit 142 registers the input information in the member database 122. New members can sign in to the sharing server 100 using the personal computer used for member registration. In this case, the personal computer functions as the recruiter device 200 or the applicant device 300.

[0145] FIG. 10 shows two applicant devices 300. One is a device intended to be operated by a manager of the applying company. The other is a device intended to be operated by someone other than the manager at the applying company. The manager of the applying company is a managerial position such as a department head, and corresponds to the superior of the subordinate applicants. In this embodiment, the manager of the applying company plays the role of an approver who approves applications for recruitment jobs from subordinates.

[0146] The member search unit 143 has a function of searching for members of the matching system 1. In response to requests from the recruiter device 200 and the applicant device 300, the member search unit 143 provides information on members registered in the member database 122 to the recruiter device 200 and the applicant device 300.

[0147] When the recruiter's device 200 receives a search operation from the recruiter, it executes a member search process (step S4A). This allows the recruiter to, for example, view applicant information. The recruiter can select an applicant from among multiple applicants to whom the job will be awarded, taking into consideration the applicant information. Similarly, when the applicant's device 300 receives a search operation for a manager who is the superior of an applicant, it executes a member search process (step S4A).

[0148] Furthermore, when the applicant device 300 receives an applicant search operation, it executes a member search process (step S4B). This allows the applicant to, for example, view information about the recruiter. The applicant can select an order from among multiple recruited jobs, taking into account the information about the recruiter.

[0149] The member search process (step S4A) executed by the recruiter device 200 and the process of the member search unit 143 will be described in detail later with reference to Fig. 19. The member search process (step S4B) executed by the applicant device 300 and the process of the member search unit 143 will be described in detail later with reference to Fig. 20.

[0150] The request registration unit 144 has a function of registering a recruitment request in the recruitment request database 124. When the recruiter device 200 receives an operation to input a recruitment request, it executes a process to register the recruitment request (step S5). In the process of registering the recruitment request, the recruiter device 200 transmits information about the recruitment request to the sharing server 100. The request registration unit 144 registers the received information about the recruitment request in the recruitment request database 124.

[0151] The recruiting request registration process (step S5) executed by the recruiter device 200 and the process of the request registration unit 144 will be described in detail later with reference to FIG.

[0152] 11 , the sharing server 100 functionally includes a case extraction unit 145, an application unit 146, an approval unit 147, and a notification unit 148. These various functions are realized by a processor 101, a memory 102, a storage 103, and a communication interface 104 that the sharing server 100 includes.

[0153] The job extraction unit 145 has a function of extracting job openings that can be viewed by applicants. The application unit 146 has a function of submitting an application by an applicant to a manager (the applicant's superior). The approval unit 147 has a function of sending the contents of the application for the job opening to the recruiter on the condition that approval of the application has been received from the manager (approver). The notification unit 148 has a function of receiving the result of whether or not to hire the applicant from the recruiter, and notifying the applicant and the manager of the result.

[0154] The application unit 146, approval unit 147, and notification unit 148 realize, by means of a workflow system, notifications to the administrator requesting approval, notifications of applicants to the recruiter, and notifications of application results to applicants.

[0155] When the applicant device 300 receives an operation from the applicant requesting a search for a job, the applicant device 300 executes a search process for the job (step S6). In the search process for the job, the applicant device 300 transmits a search request to the job extraction unit 145 of the sharing server 100.

[0156] When the case extraction unit 145 receives a search request, it extracts cases that the applicant is allowed to view from the recruitment cases registered in the recruitment case database 124, and transmits the extracted cases to the applicant device 300. The case extraction unit 145 determines whether the applicant is allowed to view the case based on a first criterion and a second criterion. The first criterion is the disclosure range set for the recruitment case. The second criterion is the applicant's spare capacity for a side job. The disclosure range is determined by the disclosure information shown in FIG. 14. The spare capacity for a side job is calculated as the available time for a side job shown in FIG. 15.

[0157] The case extraction unit 145 determines cases that satisfy both the first criterion and the second criterion as cases that are permitted for viewing by the applicant. Accordingly, the case extraction unit 145 extracts cases that are permitted for disclosure to the applicant who received the search request from among the recruitment cases registered in the recruitment case database 124. Furthermore, the case extraction unit 145 extracts cases that can be handled within the side job available time of the applicant who received the search request from among the recruitment cases registered in the recruitment case database 124. The case extraction unit 145 transmits the cases that are permitted for viewing by the applicant to the applicant device 300.

[0158] The case extraction unit 145 may be configured to accept an operation to set criteria for extracting cases. For example, a function may be added to the sharing server 100 that allows the system administrator to select one of a first setting that enables only the first criterion, a second setting that enables only the second criterion, and a third setting that enables both the first and second criteria.

[0159] The applicant device 300 receives the job listing from the job extractor 145. The applicant device 300 displays the received job listing on the display 305 (step S7).

[0160] The job search process (step S6), the job display process (step S7), and the process of the job extractor 145 will be described in detail later with reference to FIG.

[0161] The applicant operates the applicant device 300 to select an application target from the recruitment requests displayed on the display 305. The applicant device 300 executes application processing in response to the applicant's operation (step S8). In the application processing, the applicant device 300 transmits application information indicating the request to be applied for to the application unit 146 of the sharing server 100. As a result, a request to receive an order for the work is transmitted from the applicant device 300 to the application unit 146.

[0162] The application unit 146 transmits the application information received from the applicant device 30 to the applicant device 300 of the manager (the applicant's superior). The application unit 146 identifies the member ID of the applicant's superior, who is the manager, based on, for example, the relationship between the applicant's member ID and the superior's member ID registered in the member database 122. The application unit 146 transmits the subordinate's application information to the applicant device 300 corresponding to the identified superior's member ID. The manager checks the job for which the subordinate has applied on his or her own applicant device 300. The manager performs an operation to approve the application on the applicant device 300. The applicant device 300 accepts the approval operation and executes application approval processing (step S9). In the application approval processing, the applicant device 300 transmits approval information to the approval unit 147 of the sharing server 100. As a result, approval information, which is an example of an approval notice, is transmitted from the applicant device 300 of the manager (approver) to the approval unit 147.

[0163] The approval unit 147 accepts an applicant's application on the condition that approval information has been received from the applicant device 300. In this manner, in this embodiment, an applicant's application is accepted on the condition that approval is obtained from the manager to whom the applicant belongs. Therefore, the manager can check in advance the content of the job for which the subordinate is applying. As a result, confidential information can be prevented from leaking outside the company through an employee's side job.

[0164] 11 shows the flow when the manager approves an application. If an operation to reject the application is accepted in step S9, rejection information is transmitted from the applicant device 300 of the manager to the approval unit 147. If the rejection information is received, the approval unit 147 may notify the applicant device 300 of the applicant that the application has been rejected.

[0165] The approval unit 147, which has accepted the applicant's application, transmits application information to the recruiter device 200. The application information includes information about the applicant and the details of the job for which the applicant is being applied. The recruiter device 200 displays the application details on the display 205 (step S10). The recruiter checks the applicant and the job based on the display 205 and determines whether to hire the applicant.

[0166] The recruiter inputs the result of the decision on whether to hire or not to the recruiter device 200. The recruiter device 200 accepts the input result (step S11). The recruiter device 200 transmits the accepted result of hire or not to the notification unit 148 of the sharing server 100.

[0167] When the notification unit 148 receives the result of employment or rejection from the recruiter device 200, it transmits the application result (employment or rejection result) to the applicant device 300 of the applicant and the applicant device 300 of the manager.

[0168] The applicant's device 300 and the administrator's device 300 display the application results on the display 305 (steps S12 and S13). The applicant and the administrator check the application results by looking at the display 305.

[0169] 12 , the sharing server 100 functionally includes a performance result receiving unit 149, a performance result output unit 150, a rating receiving unit 151, and a rating output unit 152. These various functions are realized by a processor 101, a memory 102, a storage 103, and a communication interface 104 provided in the sharing server 100.

[0170] The performance receiving unit 149 has a function to receive the planned side job hours and actual side job hours input by the applicant on the applicant device 300. The performance output unit 150 has a function to output information including the applicant's planned side job hours and actual side job hours to the recruiter device 200 or the manager's applicant device 300.

[0171] The evaluation receiving unit 151 has a function of receiving an evaluation of an applicant (contractor) input by a recruiter in the recruiter device 200. The evaluation output unit 152 has a function of outputting information indicating an evaluation of an applicant to the recruiter device 200.

[0172] When an applicant engages in a side job, he / she inputs the planned side job hours and the actual side job hours into applicant device 300. An applicant typically inputs the planned side job hours into applicant device 300 when receiving an order for a new side job, and inputs the actual side job hours into applicant device 300 at any time while engaged in the side job. For example, if an applicant receives an order for a side job that is expected to last multiple months, the applicant inputs the actual side job hours into applicant device 300 for each month.

[0173] The applicant device 300 receives the input of the planned side job time and the actual side job time (step S14). The applicant device 300 transmits the received planned side job time and actual side job time to the result receiving unit 149 of the sharing server 100.

[0174] The result receiving unit 149 registers the received planned side job hours and actual side job hours in the side job database 125. The processing of step S14 executed by the applicant device 300 and the processing of the result receiving unit 149 will be described in detail later with reference to FIG.

[0175] The performance output unit 150 transmits the planned side job time and actual side job time registered in the side job database 125 to the recruiter device 200 and the manager's applicant device 300. The recruiter device 200 displays the received information including the planned side job time and actual side job time on the display 205, and the manager's applicant device 300 displays the received information including the planned side job time and actual side job time on the display 305 (step S15). However, when the information transmitted to the recruiter device 200 is compared with the information transmitted to the manager's applicant device 300, the cases to be transmitted are different.

[0176] Data corresponding to the cases that the subordinates are in charge of, among the many cases registered in the side job database 125, is sent from the performance record receiving unit 149 to the manager's applicant device 300. The manager can check the side job status of the subordinates by looking at the display 305. The screen displayed on the manager's applicant device 300 when the manager checks the side job status of the subordinates will be explained later using FIG. 23.

[0177] Data corresponding to the job that the recruiter has recruited from among the many jobs registered in the side job database 125 is transmitted from the achievement receiving unit 149 to the recruiter device 200. For example, consider a case in which, in the side job database 125 shown in Fig. 7, among multiple recruiters, a first recruiter has recruited for job 001 and a second recruiter has recruited for job 002.

[0178] In this case, various data corresponding to case 001 in the side job database 125 is transmitted from the achievement receiving unit 149 to the recruiter device 200 operated by the first recruiter. Various data corresponding to case 002 in the side job database 125 is transmitted from the achievement receiving unit 149 to the recruiter device 200 operated by the second recruiter.

[0179] The first recruiter and the second recruiter can check the progress of their own projects by viewing the planned side job time and actual side job time, etc., displayed on the display 305 of the recruiter device 200.

[0180] When the side job is completed, the recruiter inputs an evaluation of the applicant into the recruiter device 200. The recruiter device 200 accepts the input of the evaluation of the applicant (step S16A). Therefore, when accepting the input evaluation, the recruiter device 200 functions as an evaluator device operated by the evaluator (recruiter).

[0181] The recruiter device 200 transmits the received evaluations to the evaluation receiving unit 151 of the sharing server 100. The evaluation receiving unit 151 updates the evaluation input database 126 and the evaluation summary database 127 based on the received evaluations. As a result, the information in the applicant evaluation unit 126B is updated in the evaluation input database 126, and the information in the applicant evaluation summary unit 127B is updated in the evaluation summary database 127.

[0182] The process of step S16A executed by the recruiter device 200 and the process of the evaluation receiving unit 151 will be described in detail later with reference to FIG.

[0183] When the recruiter accepts an operation to view the applicant's evaluation, the recruiter device 200 executes a view request process (step S17A). In the view request process, the recruiter device 200 transmits a view request to the evaluation output unit 152 of the sharing server 100. In response to the view request, the evaluation output unit 152 transmits the applicant's evaluation (applicant evaluation summary) registered in the evaluation summary database 127 to the recruiter device 200. The recruiter device 200 displays the received applicant evaluation on the display 205 (step S18A).

[0184] The processes of steps S17A and S18A executed by the recruiter device 200 and the process of the evaluation output unit 152 will be described in detail later with reference to FIG.

[0185] Figure 13 is a diagram further explaining the functions of the applicant device 300. Here, the input and output of evaluations of the recruiter will be explained using Figure 13. The evaluation receiving unit 151 further has a function to receive an evaluation of the recruiter input by the applicant on the applicant device 300. The evaluation output unit 152 further has a function to output information indicating the evaluation of the recruiter to the applicant device 300. When the applicant completes the ordered work, he or she inputs an evaluation of the recruiter into the applicant device 300. There are various points that applicants can consider in evaluating the recruiter.

[0186] For example, if the applicant can communicate smoothly with the recruiter and complete the work within the appropriate time frame, the applicant will likely rate the recruiter highly. Conversely, if there are many requests for additions, changes, and revisions to the work, if too much time is spent outside the scope of the work, if instructions are communicated too slowly, or if instructions regarding revisions to the work are given unilaterally without prior consultation, the applicant will likely rate the recruiter poorly.

[0187] The applicant device 300 receives an input of an evaluation of the recruiter (step S16B). Therefore, when receiving the input evaluation, the applicant device 300 functions as an evaluator device operated by an evaluator (applicant).

[0188] The applicant device 300 transmits the received evaluation to the evaluation receiving unit 151 of the sharing server 100. The evaluation receiving unit 151 updates the evaluation input database 126 and the evaluation summary database 127 based on the received evaluation. As a result, the information in the recruiter evaluation unit 126A is updated in the evaluation input database 126, and the information in the recruiter evaluation summary unit 127A is updated in the evaluation summary database 127.

[0189] The processing of step S16B executed by applicant device 300 and the processing of evaluation receiving section 151 will be described in detail later with reference to FIG.

[0190] When the applicant device 300 receives an operation to view the applicant's evaluation of the recruiter, it executes a view request process (step S17B). In the view request process, the recruiter device 200 transmits a view request to the evaluation output unit 152 of the sharing server 100. In response to the view request, the evaluation output unit 152 transmits the evaluation of the recruiter (recruiter evaluation summary) registered in the evaluation summary database 127 to the applicant device 300. The applicant device 300 displays the received evaluation of the recruiter on the display 305 (step S18B).

[0191] The processing of steps S17B and S18B executed by applicant device 300 and the processing of evaluation output section 152 will be described in detail later with reference to FIG.

[0192] [Details of Processing by the Request Registration Unit 144 and the Recruiter Device 200] Fig. 14 is a diagram for explaining the procedure for registering a request in the request database 124. Step S5 in Fig. 10 and the function of the request registration unit 144 will be described in more detail using Fig. 14.

[0193] A recruiter who registers a recruitment request first signs in to the sharing server 100 using the recruiter device 200. This establishes a logical communication path identified by the recruiter's member ID between the recruiter device 200 and the sharing server 100. Next, the recruiter inputs business information and disclosure information for the recruitment request into the recruiter device 200 using the operation unit 206, such as a mouse and keyboard.

[0194] The information input through the operation unit 206 is notified to the processor 201 via the input / output interface 204 of the recruiter device 200. The operation unit 206 and the input / output interface 204 constitute an interface that accepts an operation to input the content of the business and an operation to input disclosure information that specifies the target to whom the business will be disclosed.

[0195] The business information for the job posting includes the job title, job content, estimated man-hours (person-months), and estimated period. The disclosure information includes the disclosure level. The disclosure information may include the IDs of companies that are not subject to disclosure, depending on the employer's choice.

[0196] The recruiter device 200 receives input of the business information and disclosure information of the recruitment request and executes a process of registering the recruitment request (step S5). In the process of registering the recruitment request, the recruiter device 200 transmits the business information and disclosure information of the recruitment request to the sharing server 100.

[0197] The request registration unit 144 of the sharing server 100 acquires information about the recruiter (step S1441). Specifically, the request registration unit 144 identifies the company to which the recruiter belongs.

[0198] The sharing server 100 stores the member ID used when a member signs in to the sharing server 100 using the recruiter device 200 or the applicant device 300. When the sharing server 100 receives any information from the recruiter device 200 or the applicant device 300 in communication established using this member ID, it identifies the member who sent the information by the member ID used to sign in.

[0199] Therefore, when business information and disclosure information for a recruitment business are received from the recruiter device 200, the case registration unit 144 uses the member ID used to sign in to identify the recruiter operating the recruiter device 200. The case registration unit 144 uses the identified member ID, the member database 122, and the company database 121 to identify the member who is the recruiter and the company to which the recruiter belongs.

[0200] Next, the request registration unit 144 executes a process of registering the solicited request in the solicited request database 124 (step S1442). Specifically, after generating a request ID, the request registration unit 144 registers, in the solicited request database 124, company information (company ID), the ID of the company to be withheld, the disclosure level, the request title, the estimated man-hours, the estimated period, and the request content in association with the generated request ID.

[0201] According to this embodiment, the recruiter can freely control the scope of disclosure of the recruitment request at the level of "within his own company," "within the community," or "without restriction." As a result, the recruiter can prevent the recruitment request from being disclosed to a specific company that the recruiter does not intend.

[0202] According to this embodiment, companies that are not to be disclosed can be set separately from the disclosure level. Therefore, the recruiter can set the disclosure range by excluding some of the companies that have a community relationship with the recruiter's company. As a result, it is possible to prevent business related to a specific company in the community from being disclosed to that specific company.

[0203] Instead of or in addition to the non-disclosure company ID list, a non-disclosure member ID list for registering member IDs for which disclosure of recruitment proposals is prohibited may be provided in the recruitment proposal database 124. The recruiter device 200 may accept an operation to designate a member for whom disclosure of recruitment proposals is prohibited, and transmit the member's ID to the sharing server 100. The sharing server 100 may not provide recruitment proposals corresponding to a member whose member ID is listed on the non-disclosure member ID list. In this way, the recruiter device 200 may accept either a company or a member as a target for which disclosure of business proposals is prohibited.

[0204] Fig. 15 is a diagram for explaining the procedure for searching for recruitment requests from the database 120. The processes of steps S6 and S7 in Fig. 11 and the function of the request extraction unit 145 will be explained in more detail with reference to Fig. 15.

[0205] When the applicant device 300 receives an operation from the applicant requesting a search for a job, the applicant device 300 executes a search process for the job (step S6). In the search process for the job, the applicant device 300 transmits a search request to the job extraction unit 145 of the sharing server 100.

[0206] When the request extraction unit 145 receives a search request, it extracts requests that the applicant is permitted to view from among the requests registered in the request database 124. To this end, the request extraction unit 145 executes the processes of steps S1451 to S1454.

[0207] Steps S1451 and S1452 are processes for extracting applications that are permitted for viewing by applicants based on the disclosure scope set for the applications. In step S1451, the applicant's company and the company's community are determined. In step S1452, applications that can be disclosed are extracted.

[0208] Step S1453 is a process for extracting jobs that the applicant is allowed to view based on the applicant's spare capacity for a side job. Step S1454 is a process for finally extracting jobs that match the applicant.

[0209] [Process for Extracting Cases Based on Disclosure Scope] Step S1451 includes step S1451A and step S1451B.

[0210] In step S1451A, the company to which the applicant belongs is identified based on the member ID used at the time of signing in, company database 121, and member database 122.

[0211] In step S1451B, the community of the company to which the applicant belongs is identified based on the ID of the company to which the applicant belongs and the community database 123.

[0212] Step S1452 includes steps S1452 A and S1452 B. In step S1452 A, discloseable recruitment requests are extracted from the recruitment request database 124 based on the community to which the applicant's company belongs and the disclosure level.

[0213] In step S1452B, from the jobs extracted in step S1452A, jobs for which the applicant's company is included in the non-disclosure company list are excluded. Here, the job extracted by the processing of step S1452B is referred to as job X.

[0214] [Process for Extracting Cases Based on Abundance of Side Jobs] Step S1453 includes step S1453A, step S1453B, and step S1453C.

[0215] In step S1453A, the applicant's allowable side job time T1 is calculated. The allowable side job time is derived by calculating "side job limit time - total side job time." The side job limit time is a time set by the company to which the applicant belongs, and is registered in the company database 121. The calculated allowable side job time is registered in the member database 122. The case extraction unit 145 may calculate the allowable side job time for all members at regular intervals, and register the calculated allowable side job time in the member database 122.

[0216] The total side job time is calculated using the formula "total expected side job time + total actual side job time" based on the expected side job time and actual side job time registered in the side job database 125. In other words, the total side job time includes the time already spent on the side job as well as the expected time not yet spent on the side job.

[0217] In step S1453B, the time T2 required to complete the work is calculated for each job. The time T2 is calculated based on the estimated man-hours (man-months) and estimated period registered in the job database 124. For example, the estimated man-hours (months) may be used as the time T2. For example, for the job corresponding to job ID 001, 5 hours per month may be set as the time T2.

[0218] In step S1453C, jobs that satisfy the condition "time T2≦time available for side job T1" are extracted from the job database 124. Here, the job extracted by the processing in step S1453C is referred to as job Y.

[0219] [Process for extracting cases based on disclosure range and side job capacity] The case extraction unit 145 extracts case X based on disclosure range, extracts case Y based on side job capacity, and then extracts cases that overlap between case X and case Y as matching cases for the applicant (step S1454).

[0220] [Process for Providing Extracted Projects] Next, the project extraction unit 145 transmits information about the matching projects to the applicant device 300 (step S1455). The applicant device 300 receives the matching projects. The applicant device 300 displays a list of the received matching projects as recruiting projects on the display 305 (step S7).

[0221] This provides applicants with job postings that are appropriate from two perspectives. First, applicants are provided with job postings that can be handled within the applicant's side job limit. This prevents applicants from becoming overworked. Second, the recruiter's job postings are provided only to applicants who fall within the scope of disclosure intended by the recruiter. This prevents confidential information of the recruiter's company from being leaked to competitors.

[0222] [Process for Registering Planned Side Job Time and Actual Side Job Time] Fig. 16 is a diagram for explaining the procedure for registering planned and actual side jobs in the database 120. Using Fig. 16, step S14 in Fig. 12 and the function of the actual job receiving unit 149 will be described in more detail.

[0223] For example, when an applicant receives an order for a new side job, the applicant inputs the planned side job time into applicant device 300, and inputs the actual side job time at any time while engaged in the side job into applicant device 300. Applicant device 300 accepts the input of the planned side job time (step S14). Applicant device 300 transmits the accepted planned side job time and actual side job time to performance acceptance unit 149 of sharing server 100.

[0224] The performance receiving unit 149 receives the applicant's planned side job hours and actual side job hours, and registers the received applicant's planned side job hours and actual side job hours in the side job database 125 (step S1511). As a result, the applicant's planned side job hours and actual side job hours for each month are registered in the side job database 125 by case ID.

[0225] Typically, after an applicant inputs the planned hours for a side job, the applicant also inputs the actual hours for the side job at the end of the current month. For this reason, the side job database 125 may include cases in which the planned hours for the side job are registered but the actual hours for the side job are not. For example, when an applicant who has received an order for a side job inputs the planned hours for the side job, the planned hours for the side job are registered as data corresponding to that side job, but the actual hours for the side job are not registered.

[0226] Next, the result receiving unit 149 automatically calculates the expected side job time for the current month (step S1512). The result receiving unit 149 calculates the expected side job time based on the planned side job time and the actual side job time. Specifically, as already explained, the "expected side job time" is calculated based on the calculation formula "(man-hour progress rate / progress rate) × planned side job time - actual side job time." Note that the result receiving unit 149 may also calculate the "expected side job time" using the calculation formula "planned side job time - actual side job time." The result receiving unit 149 registers the calculated expected side job time in the side job database 125. As shown in the side job database 125 in FIG. 7, the expected side job time is registered for each project ID.

[0227] [Process for Registering Evaluation Results (Evaluation of Applicant)] Fig. 17 is a diagram for explaining the procedure for registering an evaluation of an applicant in database 120. Using Fig. 17, step S16A in Fig. 12 and the function of evaluation receiving unit 151 will be described in more detail.

[0228] When the applicant completes the side job, he / she delivers and reports completion to the recruiter, and undergoes inspection by the recruiter. The recruiter then operates the recruiter device 200 to input an evaluation of the applicant into the recruiter device 200. The recruiter device 200 accepts the input evaluation (step S16A). The recruiter device 200 transmits the accepted evaluation to the evaluation acceptance unit 151 of the sharing server 100. The information transmitted from the recruiter device 200 to the sharing server 100 includes the member ID and evaluation value (0 to 10) of the applicant to be evaluated.

[0229] When the evaluation receiving unit 151 receives information on the evaluation of the person being evaluated (applicant) from the recruiter device 200, it reflects the evaluation of the person being evaluated in the evaluation input database 126 (step S1513A).

[0230] If evaluation results for the evaluatee (applicant) have already been registered in the evaluation input database 126, the evaluation receiving unit 151 calculates the average value of the evaluation results for the evaluatee, including the value of the evaluation received this time. The evaluation receiving unit 151 updates the evaluation results registered in the evaluation input database 126 with the calculated average value. As a result, the average values ​​of the evaluations (evaluation results) for the evaluatee (applicant) are registered for each evaluator (recruiter) in the evaluation input database 126. This updates the information in the applicant evaluation unit 126B in the evaluation input database 126.

[0231] Next, the evaluation receiving unit 151 executes evaluation summary processing (step S1514A). In the evaluation summary processing, the evaluation receiving unit 151 calculates the average value of the evaluation results for the evaluatee (applicant) by company and department, and registers the calculation results in the evaluation summary database 127. As a result, the information in the applicant evaluation summary section 127B in the evaluation summary database 127 is updated.

[0232] For example, the evaluation receiving unit 151 identifies the evaluator (recruiter) using the member ID used by the recruiter device 200 to sign in to execute step S16A. Based on the evaluation information received in step S1513A, the company database 121, and the member database 122, the evaluation receiving unit 151 identifies the ID of the company to which the evaluator belongs, the department to which the evaluator belongs, the member ID of the person being evaluated, and the ID of the company to which the person being evaluated belongs. The "member ID" is an example of "identification information that enables the sharing server 100 including the evaluation receiving unit 151 to identify the affiliation (company and department) of a person accessing the sharing server 100."

[0233] The evaluation receiving unit 151 accesses the evaluation summary database 127 and detects a data row containing the specified IDs (the member ID of the person being evaluated, the ID of the company to which the person being evaluated belongs, and the ID of the company to which the evaluator belongs). The evaluation receiving unit 151 updates the value of the applicant evaluation summary corresponding to the detected data row.

[0234] [Process for Registering Evaluation Results (Evaluation of Recruiter)] Fig. 18 is a diagram for explaining the procedure for registering evaluations of recruiters in the database. Using Fig. 18, step S16B in Fig. 13 and the function of the evaluation receiving unit 151 will be described in more detail.

[0235] As described above, when the applicant completes the side job, he / she delivers and reports completion to the recruiter, and the applicant undergoes inspection by the recruiter. The applicant then operates the applicant device 300 to input an evaluation of the recruiter into the applicant device 300. The applicant device 300 accepts the input evaluation (step S16B). The applicant device 300 transmits the accepted evaluation to the evaluation acceptance unit 151 of the sharing server 100. The information transmitted from the applicant device 300 to the sharing server 100 includes the member ID of the recruiter who is being evaluated, and the evaluation value (0 to 10).

[0236] When the evaluation receiving unit 151 receives information on the evaluation of the evaluatee (recruiter) from the applicant device 300, it reflects the evaluation of the evaluatee in the evaluation input database 126 (step S1513B).

[0237] If evaluation results for the ratee (recruiter) have already been registered in the evaluation input database 126, the evaluation receiving unit 151 calculates the average value of the evaluation results for the ratee, including the value of the evaluation received this time. The evaluation receiving unit 151 updates the evaluation results registered in the evaluation input database 126 with the calculated average value. As a result, the average values ​​(evaluation results) of the evaluations for the ratee (recruiter) are registered for each evaluator (applicant) in the evaluation input database 126. This updates the information in the recruiter evaluation unit 126A in the evaluation input database 126.

[0238] Next, the evaluation receiving unit 151 executes evaluation summary processing (step S1514B). In the evaluation summary processing, the evaluation receiving unit 151 calculates the average value of the evaluation results for the evaluatee (recruiter) by company and department, and registers the calculation results in the evaluation summary database 127. As a result, the information in the recruiter evaluation summary unit 127A is updated in the evaluation summary database 127.

[0239] For example, the evaluation receiving unit 151 identifies the evaluator (applicant) using the member ID used by the applicant device 300 to sign in to execute step S16B. Based on the evaluation information received in step S1513B, the company database 121, and the member database 122, the evaluation receiving unit 151 identifies the ID of the company to which the evaluator belongs, the department to which the evaluator belongs, the member ID of the person being evaluated, and the ID of the company to which the person being evaluated belongs. The "member ID" is an example of "identification information that enables the sharing server 100 including the evaluation receiving unit 151 to identify the affiliation (company and department) of a person accessing the sharing server 100."

[0240] The evaluation receiving unit 151 accesses the evaluation summary database 127 and detects a data row containing the specified IDs (the member ID of the person being evaluated, the ID of the company to which the person being evaluated belongs, and the ID of the company to which the evaluator belongs). The evaluation receiving unit 151 updates the value of the recruiter evaluation summary corresponding to the detected data row.

[0241] For example, data group 1271 in Fig. 9 includes the member ID of the person being evaluated = P1, the ID of the company to which the person being evaluated belongs = 00A, and the ID of the company to which the evaluator belongs = 00B. When a member belonging to the systems department of company B evaluates member P1, the evaluation is accepted in step S1513B.

[0242] In this case, in step S1514B, the evaluation received in step S1513B is reflected in the recruiter evaluation summary corresponding to the "whole" of data group 1271 and the recruiter evaluation summary corresponding to the "system section."

[0243] More specifically, the evaluation receiving unit 151 sets the average value of the evaluations of the entire company B, including the evaluations received in step S1513B, as the recruiter evaluation summary corresponding to "Overall" in the data group 1271. Similarly, the evaluation receiving unit 151 sets the average value of the evaluations of the system part, including the evaluations received in step S1513B, as the recruiter evaluation summary corresponding to "System part" in the data group 1271.

[0244] Fig. 19 is a diagram for explaining the procedure for displaying the evaluation of an applicant and the search results of members on the display 205. Using Fig. 19, step S4A (processing of the recruiter device 200) and the function of the member search unit 143 in Fig. 10, as well as steps S17A and S18A in Fig. 12 and the function of the evaluation output unit 152 will be explained in more detail.

[0245] [Processing for Outputting Applicant Evaluation Summary] First, the processing of steps S17A, S18A, S1521A, and S1522A shown in FIG. 19 will be described.

[0246] When the recruiter accepts an operation to view the evaluation of an applicant, the recruiter device 200 executes a view request process (step S17A). In the view request process, the recruiter device 200 transmits a view request to the evaluation output unit 152 of the sharing server 100. In response to the view request, the evaluation output unit 152 selects from the evaluation summary database 127 an applicant evaluation summary for which the recruiter (view requester) has permission to view (step S1521A).

[0247] The recruiter who made the viewing request is authorized to view the applicant evaluation summary for the entire company to which the recruiter belongs and the applicant evaluation summary for the department to which the recruiter belongs. The recruiter who made the viewing request is not authorized to view any evaluation summaries other than these. The evaluation output unit 152 determines the viewing authority based on the member ID of the recruiter who sent the viewing request, the company database 121, and the member database 122. The "member ID" is an example of "identification information that allows the sharing server 100 including the evaluation receiving unit 151 to identify the affiliation (company and department) and viewing authority of a person who has accessed the sharing server 100."

[0248] The evaluation output unit 152 selects an applicant evaluation summary corresponding to the viewing authority from the evaluation summary database 127. The evaluation output unit 152 transmits data including the selected applicant evaluation summary to the recruiter device 200 (step S1522A). In addition to the applicant evaluation summary, the transmitted data includes the applicant's (evaluated) membership ID, information about the company to which the applicant belongs, information about the department to which the applicant belongs, etc. The transmitted data may include applicant evaluation summaries corresponding to each of multiple applicants (evaluated), depending on the viewing request.

[0249] Upon receiving the applicant evaluation summary, the recruiter device 200 displays the applicant evaluation summary on the display 205 together with information about the company to which the applicant belongs and information about the department to which the applicant belongs (step S18A). When applicant evaluation summaries corresponding to multiple applicants (evaluated persons) are received, the recruiter device 200 displays the applicant evaluation summaries in a list of multiple applicants (evaluated persons).

[0250] In this way, when the sharing server 100 receives a viewing request in communication established by a member ID that can identify the company and department to which the recruiter belongs, it sends an applicant evaluation summary, which is an example of evaluation information, to the recruiter device 200 of the recruiter that sent the viewing request.

[0251] [Process for Searching for Members (Applicants)] Next, with reference to FIG. 19, the processes in steps S4A, S19A, and S1431A to S1433A will be described.

[0252] When the recruiter device 200 receives a search operation from the recruiter, it executes a member search process to search for information about the applicant (step S4A). In the member search process, the recruiter device 200 transmits a search request to the member search unit 143 of the sharing server 100. The search request includes a reference value for excluding members with low applicant evaluations from the search. This reference value is determined, for example, based on the value of the applicant evaluation summary.

[0253] The member search unit 143, which has received the search request, identifies the company to which the recruiter who sent the search request belongs (step S1431A). Here, the company identified in step S1431A is referred to as "company Xa."

[0254] The member search unit 143 identifies the recruiter operating the recruiter device 200 by using the member ID used when the recruiter device 200 signed in to the sharing server 100. The member search unit 143 identifies the company Xa to which the recruiter belongs by using the company database 121 and the member database 122.

[0255] Next, the member search unit 143 extracts from the evaluation summary database 127 members whose applicant evaluation summary values ​​for the identified company Xa as a whole exceed a reference value (step S1432A). In other words, the member search unit 143 extracts search results by excluding members who have low evaluations for the company Xa as a whole.

[0256] It should be noted here that the member search unit 143 determines whether the evaluation is low based on the applicant evaluation summary. That is, member α, who has the authority of both an applicant and a recruiter, may act as an applicant or as a recruiter. Therefore, as evaluation summaries for such member α, an applicant evaluation summary and a recruiter evaluation summary are registered in the evaluation summary database 127. Member α may have a high evaluation as a recruiter but a low evaluation as an applicant. In this case, member α may be excluded from the extraction targets in step S1432A.

[0257] The sharing server 100 may be provided with a function for receiving setting information of the reference value from the recruiter device 200 of each company. This allows each company to exclude members with low evaluations based on their own reference value from the search results.

[0258] Next, the member search unit 143 outputs the extracted member information as a search result to the recruiter device 200 that made the search request (step S1433A). The recruiter device 200 displays the received search results in a list on the display 205 (step S19A).

[0259] As a result, the recruiter can view the search results excluding members whose companies have low overall ratings on the display 205. Therefore, when selecting contractors from among applicants, the recruiter can save the trouble of visually excluding members whose companies have low overall ratings.

[0260] In this embodiment, even if a member has a low evaluation of a department of the company to which the recruiter belongs, the member will not be excluded from the search results if the evaluation of the company as a whole is not low. However, the member search unit 143 may further exclude such a member from the search results.

[0261] Fig. 20 is a diagram for explaining the procedure for displaying evaluations of recruiters and search results of members on the display 305. Using Fig. 20, step S4B (processing of applicant device 300) and the function of member search unit 143 in Fig. 10, as well as steps S17B and S18B in Fig. 13 and the function of evaluation output unit 152 will be explained in more detail.

[0262] [Processing for Outputting Recruiter Evaluation Summary] First, the processing of steps S17B, S18B, S1521B, and S1522B shown in FIG. 20 will be described.

[0263] When the applicant device 300 receives an operation to view the applicant's evaluation of the recruiter, the applicant device 300 executes a view request process (step S17B). In the view request process, the applicant device 300 transmits a view request to the evaluation output unit 152 of the sharing server 100. In response to the view request, the evaluation output unit 152 selects from the evaluation summary database 127 a recruiter evaluation summary for which the applicant (view requester) has permission to view (step S1521B).

[0264] An applicant who has made a viewing request is authorized to view the recruiter evaluation summary for the entire company to which the applicant belongs and the recruiter evaluation summary for the department to which the applicant belongs. An applicant who has made a viewing request is not authorized to view any evaluation summaries other than these. The evaluation output unit 152 determines the viewing authority based on the member ID of the applicant who sends the viewing request, the company database 121, and the member database 122. The "member ID" is an example of "identification information that allows the sharing server 100 including the evaluation receiving unit 151 to identify the affiliation (company and department) and viewing authority of a person who has accessed the sharing server 100."

[0265] The evaluation output unit 152 selects a recruiter evaluation summary corresponding to the viewing authority from the evaluation summary database 127. The evaluation output unit 152 transmits data including the selected recruiter evaluation summary to the applicant device 300 (step S1522B). The transmitted data includes the recruiter evaluation summary as well as the member ID of the recruiter (person being evaluated), information about the company to which the recruiter belongs, information about the department to which the recruiter belongs, etc. The transmitted data may include recruiter evaluation summaries corresponding to each of multiple recruiters (persons being evaluated) depending on the viewing request.

[0266] Upon receiving the recruiter evaluation summary, the applicant device 300 displays the recruiter evaluation summary together with information about the company to which the recruiter belongs and information about the department to which the recruiter belongs on the display 305 (step S18B). When receiving recruiter evaluation summaries corresponding to multiple recruiters (evaluated persons), the applicant device 300 displays the recruiter evaluation summaries in a list of multiple recruiters (evaluated persons).

[0267] In this way, when the sharing server 100 receives a viewing request in communication established using a member ID that can identify the company and department to which the applicant belongs, it sends a recruiter evaluation summary, which is an example of evaluation information, to the applicant device 300 of the applicant who sent the viewing request.

[0268] [Processing for Searching for Members (Recruiters)] Next, with reference to FIG. 20, the processing in steps S4B, S19B, and S1431B to S1433B will be described.

[0269] When the applicant device 300 receives a search operation from the applicant, it executes a member search process to search for information about the recruiter (step S4B). In the member search process, the applicant device 300 transmits a search request to the member search unit 143 of the sharing server 100. The search request includes a reference value for excluding members with low ratings as recruiters. This reference value is determined, for example, based on the value of the recruiter evaluation summary.

[0270] Upon receiving the search request, the member search unit 143 identifies the company to which the applicant who sent the search request belongs (step S1431B). Here, the company identified in step S1431B is referred to as "company Xb."

[0271] The member search unit 143 identifies the applicant operating the applicant device 300 by using the member ID used when the applicant device 300 signed in to the sharing server 100. The member search unit 143 uses the company database 121 and the member database 122 to identify the company Xb to which the applicant belongs.

[0272] Next, the member search unit 143 extracts members whose recruiter evaluation summary values ​​for the entire identified company Xb exceed a reference value from the evaluation summary database 127 (step S1432B). In other words, the member search unit 143 extracts search results by excluding members whose evaluations of the entire company Xb are low.

[0273] The sharing server 100 may be provided with a function for receiving setting information of the reference value from the recruiter device 200 of each company. This allows each company to exclude members with low evaluations based on their own reference value from the search results.

[0274] Next, the member search unit 143 outputs the extracted member information as a search result to the applicant device 300 that issued the search request (step S1433B). The applicant device 300 displays a list of the received search results on the display 305 (step S19B).

[0275] As a result, the applicant can view the search results excluding members whose companies have low overall ratings on the display 305. Therefore, when selecting a contractor from among the recruiters, the applicant can save the trouble of visually excluding members whose companies have low overall ratings.

[0276] In this embodiment, even if a member has a low evaluation for a certain department of the company to which the applicant belongs, the member will not be excluded from the search results if the evaluation for the company as a whole is not low. However, the member search unit 143 may further exclude such a member from the search results.

[0277] [Viewable Range of Evaluation Summary Database 127] Fig. 21 is a diagram for explaining the viewable range of the evaluation summary database 127. Here, the viewable range will be explained using the recruiter evaluation summary section 127A of the evaluation summary database 127, which is also shown in Fig. 9, as an example.

[0278] The recruiter evaluation summary section 127A shown in Figure 21 includes evaluation summaries from companies B and C for member P1, who acts as a "recruiter." Member P1 belongs to company A. Company B's evaluation summary is categorized into "overall," "system department," and "planning department." Company C's evaluation summary is categorized into "overall," "planning department," etc. Members belonging to companies B and C view the evaluation summaries for member P1 as "applicants."

[0279] The viewing authority for the evaluation summary calculated from the overall evaluation of company B is granted to all members belonging to company B, as shown in the "viewable range" column in FIG.

[0280] The right to view the evaluation summary calculated from the evaluation of the Systems Department of Company B is granted to members of the Systems Department of Company B, but not to members other than the Systems Department of Company B. The right to view the evaluation summary calculated from the evaluation of the Planning Department of Company B is granted to members of the Planning Department of Company B, but not to members other than the Planning Department of Company B.

[0281] The right to view the evaluation summary calculated from the overall evaluation of Company C is granted to all members belonging to Company C. The right to view the evaluation summary calculated from the evaluation of the Planning Department of Company C is granted to members of the Planning Department of Company C, but not to members other than those of the Planning Department of Company C.

[0282] The above has described the viewable range using the recruiter evaluation summary section 127A as an example. In the matching system 1, the viewable range for the applicant evaluation summary section 127B (see FIG. 9) is also determined based on the same design concept as for the recruiter evaluation summary section 127A.

[0283] If the viewers are members of Company X's first division and Company X's second division, the viewers' authority to the overall evaluation summary of Company X, the evaluation summary of Company X's first division, and the evaluation summary of Company X's second division will be as shown in Table 401 in Figure 21. Here, when the applicant corresponds to the "viewer," the object to be viewed is the evaluation summary of the "recruiter." Conversely, when the recruiter corresponds to the "viewer," the object to be viewed is the evaluation summary of the "applicant."

[0284] A member belonging to the first division of company X can view the evaluation summary for company X as a whole and the evaluation summary for company X's first division, but cannot view the evaluation summary for company X's second division. A member belonging to the second division of company X can view the evaluation summary for company X as a whole and the evaluation summary for company X's second division, but cannot view the evaluation summary for company X's second division. A member belonging to company Y other than company X cannot view the evaluation summary for company X as a whole, the evaluation summary for company X's first division, and the evaluation summary for company X's second division.

[0285] The evaluation summary of company X as a whole, the evaluation summary of company X's first division, and the evaluation summary of company X's second division will not be disclosed to members of companies other than company X. Therefore, when evaluating a recruiter belonging to company X, a member belonging to company Y and acting as an applicant can objectively evaluate the recruiter belonging to company X without considering the relationship between the companies, etc. Similarly, when evaluating an applicant belonging to company X, a member belonging to company Y and acting as a recruiter can objectively evaluate the applicant belonging to company X without considering the relationship between the companies, etc.

[0286] Furthermore, evaluations made by members of Company X (evaluations of recruiters and applicants) are shared within Company X as recruiter evaluation summaries and applicant evaluation summaries. This allows evaluators to be aware that the accumulation of each evaluation produces useful information. This motivates evaluators to make accurate evaluations.

[0287] As a result, the accuracy of the recruiter evaluation summary and the applicant evaluation summary is improved. This allows the recruiter evaluation summary to be usefully used as reference data when selecting a job to be recruited for. Similarly, the applicant evaluation summary can be usefully used as reference data when selecting a contractor.

[0288] Furthermore, according to this embodiment, when the recruiter device 200 executes the member search process (step S4A), the search results excluding low-rated members are provided to the recruiter (step S1432A). Similarly, when the applicant device 300 executes the member search process (step S4B), the search results excluding low-rated members are provided to the recruiter (step S1432B). In other words, the matching system 1 has a filtering function that provides search results excluding low-rated members.

[0289] Therefore, when deciding on a contractor for a job, the recruiter can prevent, on a company-by-company basis, the mistaken hiring of a member with a low evaluation. Similarly, when deciding on a job to apply for from among a large number of jobs, the applicant can prevent, on a company-by-company basis, the mistaken selection of a job that is being recruited by a member with a low evaluation. The sharing server 100 may also perform filtering using the evaluation summary for each department.

[0290] A command signal instructing which of filtering using the evaluation summary for the entire company or filtering using the evaluation summary for each department to use may be transmitted from the recruiter device 200 to the sharing server 100. In this case, the sharing server 100 is provided with a function to change the evaluation summary used for filtering in response to the command signal.

[0291] [Example in which the disclosure range is set according to the disclosure level] Figure 22 is a diagram showing an example in which the disclosure range is set according to the disclosure level. Here, as shown in Figure 22, consider a case in which companies A to E form a community relationship, and company F does not form a community relationship with any company. In this case, the disclosure range of the job for which information is being recruited will be as shown in Table 402, depending on the company to which the recruiter belongs and the disclosure level set by the recruiter.

[0292] The disclosure levels "Level 1" to "Level 3" shown in FIG. 22 correspond to the three levels of "Company," "Within Community," and "All" already explained. Therefore, at Level 1, the recruiter's job posting is disclosed only to applicants who belong to the same company as the recruiter's company. At Level 2, the recruiter's job posting is disclosed to applicants who belong to companies that have a community relationship with the recruiter's company, in addition to the scope of Level 1. At Level 3, the recruiter's job posting is disclosed to applicants who belong to all companies, including the recruiter's company. However, if the recruiter specifies a company ID that is not to be disclosed, the company corresponding to that company ID is excluded from the companies to be disclosed, regardless of the disclosure level set. Of the disclosure levels in this embodiment, "Level 1" corresponds to "permitting disclosure of business information to the first applicant and prohibiting disclosure of business information to applicants who do not belong to the first group." "Level 2" corresponds to "allowing the disclosure of business information to applicants who belong to either the first group or a community group that has formed a community relationship with the first group, and prohibiting the disclosure of business information to applicants who do not belong to either the first group or a community group." "Level 3" corresponds to "allowing the disclosure of business information to applicants regardless of the group to which the applicant belongs."

[0293] Here, the above-mentioned levels 1 to 3 have been described as an example of multiple disclosure levels. However, the multiple disclosure levels are not limited to these. For example, a community may be divided into multiple small communities, and whether or not to disclose recruitment services may be set for each small community. More specifically, community 02 shown in FIG. 5 is divided into a first small community and a second small community. Company C belongs to the first small community, and companies D and E belong to the second small community. In this case, the recruiter of company D may be able to select whether to disclose the scope of his or her recruitment services within the scope of the first small community or the scope of the second small community.

[0294] The sharing server 100 may accept an operation to set a different disclosure range for each solicited case. For example, among the many solicited cases, cases 001 to 003 will be used as examples to explain a specific example of setting a different disclosure range for each solicited case.

[0295] For example, the disclosure range of job 001 may be limited to only companies A and C that belong to the community identified by community ID=03. Alternatively, the disclosure range of job 002 may be limited to only companies C, D, and E that belong to the community identified by community ID=02. Alternatively, the disclosure range of job 003 may be limited to companies C, D, and E that belong to the community identified by community ID=02 and companies A and C that belong to the community identified by community ID=03.

[0296] Company A may form a community separate from the community identified by community ID=01 or 02. For example, as shown by the dashed line in FIG. 22 , company A may form a community identified by community ID=Z with company Z. For example, if a recruiter belongs to company A, the recruiter's job postings may be disclosed to applicants belonging to company A and applicants belonging to company Z. This level of disclosure may be adopted as a variation of "Level 3" as shown in FIG. 22 .

[0297] In this case, "Level 3" corresponds to "allowing disclosure of business information to applicants who belong to a specific community group (a community identified by community ID = Z) that is different from the first group (Company A) and the second-level community groups (Companies A to C) that have formed community relationships with the first group, and prohibiting disclosure of business information to applicants who do not belong to either the first group or the specific community group."

[0298] Here, levels 1 to 3 have been described as an example of multiple levels, but even more levels may be set as multiple types of disclosure levels. As an example of an interface for the recruiter to set the disclosure range, a screen may be displayed on the user device 500 that displays check boxes for setting a desired level from multiple types of levels.

[0299] [Example of a screen displayed when checking the side job status] Figure 23 is a diagram showing a screen displayed on the applicant device 300 of a manager (an applicant's boss) when the manager checks the side job status of his or her subordinates. Figure 23 shows an example in which the side job status of the manager's subordinates is displayed on the applicant device 300. The applicant device 300 is provided with a keyboard 306A and a mouse 306B as operation units.

[0300] In this example, the manager is, for example, the head of the sales department of company C. The side job status of employees in the sales department is shown on display 305. The manager can check the side job status of employees in the sales department by selecting tab 307A, tab 307B, tab 307C, etc. with keyboard 306A or mouse 306B. This allows the manager to manage the working hours of subordinates so that they do not fall into a state of overwork. The progress rate may also be displayed on the screen.

[0301] [Details of the job content] Fig. 24 is a diagram showing details of the job content included in the job recruitment database 124. The job content includes recruitment requirements. As shown in Fig. 24, the job content is registered in the job recruitment database 124 by job ID.

[0302] The job content includes a job detail item. This item includes text that explains the job content. This text includes the specific content of the job as well as the skills, experience, and qualifications required of applicants. Required skills refer to the skills required for the job. Required experience refers to the number of years of work experience using the required skills. Required qualifications refer to national qualifications, private qualifications, etc.

[0303] The project details further include the items of the client and the client's company. The client is the person who proposed the project, i.e., the solicitor. The client's company is the name of the company to which the solicitor belongs.

[0304] The project details further include the following items: timing, unit price (unit cost per man-hour), planned total time, and actual total time. Timing refers to when the work will begin. Unit price (unit cost per man-hour) refers to the wage per unit time. Planned total time refers to the planned time from the start to the end of the work. Planned total time changes depending on the progress of the project related to the work. Actual total time refers to the time calculated by reviewing the time until project completion depending on the progress of the project related to the work.

[0305] The job details are made public to users (applicants) who are permitted to disclose the job. The sentences included in the job details may contain company terms. The company terms in such sentences are registered in the job database 124 as "index information" so that they can be linked to company terms in the company terminology database 136 (described later).

[0306] As already explained with reference to FIG. 1 , the user device 500 displays the in-house term in a different display mode from other terms. This allows the user to understand that the term is an in-house term. Furthermore, the user device 500 displays the intended meaning of the in-house term in response to a user operation (for example, a click on the in-house term).

[0307] Applicants consider the details of the projects and decide which one they would like to apply for from among the many available. Before finally applying for the project, applicants will interview the project recruiter as necessary. In addition, after selecting a specific person from the applicants as a provisional contractor, the recruiter may interview the provisional contractor before entering into a business contract. After entering into a business contract with the applicant, the recruiter may interview the applicant (contractor) regarding the work details depending on the progress of the work.

[0308] The user device 500 may provide the recruiter and the applicant with a web conference environment for conducting these interviews. When a sentence including an in-house term is displayed on the display during the web conference, the user device 500 may display the in-house term in the manner shown in FIG. 1 .

[0309] [Outline of the case information distribution function] Fig. 25 is a diagram showing an outline of the case information distribution function provided in the matching system 1. Among the users (members) of the matching system 1, a user who belongs to company A is the case owner (recruiter) here. Users who belong to company B and company C each work in the production technology department. Company A and company C are in a competitive relationship. Company A and company B are not in a competitive relationship.

[0310] A project owner uploads a project related to a solution system for a factory to the matching system 1. For example, the project may be the development of a solution system. The project owner wishes to distribute project information about recommended projects to users who are interested in solution systems for factories. The project owner believes that users related to production technology are the target audience. However, the project owner does not want the project information to be distributed to users of competing companies.

[0311] The matching system 1 has a function of analyzing the attributes and behavioral history of all users and selecting users who are estimated to be highly interested in the content of the project. Therefore, the matching system 1 can distribute project information to appropriate users without obtaining information about the characteristics of the users to whom the project information is to be distributed from the project owner. In this example, the information about the user's characteristics is information about the department (production technology) to which the target user belongs. Therefore, in the example shown in FIG. 25 , excluding issues of competitive relationships, the matching system 1 can select users who belong to the production technology departments of Company B and Company C as targets.

[0312] The matching system 1 has registered therein a non-disclosure list 1291. The non-disclosure list 1291 is an example of data capable of identifying competitive relationships between companies. The non-disclosure list 1291 indicates the relationship between the company ID of the project owner and the company IDs (non-disclosure company IDs) of companies to which the project owner does not want to disclose their projects. The matching system 1 uses the non-disclosure list 1291 to identify that companies A and C are in a competitive relationship. The matching system 1 excludes users belonging to company C from targets. The matching system 1 distributes project information to users of company B, which is not in a competitive relationship with company A, but does not distribute project information to users of company C, which is in a competitive relationship with company A. Note that the non-disclosure list 1291 may be generated, for example, based on the processing of step S1452 in FIG. 15 .

[0313] Companies participating in the matching system 1 can effectively distribute their project information to companies that are thought to be interested in their projects. The matching system 1 prevents the project owner's project information from being distributed to companies that are in a competitive relationship with the project owner. Therefore, the project owner does not need to worry about the possibility of their project information being distributed to competing companies.

[0314] In particular, the matching system 1 realizes this type of job distribution by utilizing a platform for providing crowdsourcing between companies, which has the following advantages over commonly available targeted advertising systems:

[0315] In general targeted advertising systems, similar to the matching system 1, user attributes and behavioral history are analyzed to determine targets for delivery. However, there is a significant difference in the reliability of the data analyzed between general targeted advertising systems and the matching system 1. As will be explained later, the matching system 1 extracts user attributes based on highly reliable member data registered in the database 21. Therefore, the accuracy of the attribute information extracted for recommended cases is extremely high.

[0316] Furthermore, the matching system 1 analyzes the user's behavioral history using the user device 500 used by the user as a recruiter or applicant. A user who operates the user device 500 will likely input information about work in which they are interested into the user device 500. A user who operates the user device 500 will likely search the user device 500 for information about work in which they are interested. A user who operates the user device 500 is likely to use the user device 500 often for business purposes and rarely use the user device 500 for personal purposes such as hobbies. Therefore, the behavioral history information obtained from the user device 500 contains little noise and a lot of information that is useful for analyzing the delivery destinations of recommended jobs.

[0317] The matching system 1 has the above-mentioned advantages over commonly available targeted advertising systems. Therefore, the matching system 1 allows a group of companies to effectively provide recommended project information to other groups, while preventing recommended projects from being distributed to competing groups. As a result, the company that owns the project can expect a sufficient return on the cost of distributing the recommended project.

[0318] The matching system 1 may acquire information about the characteristics of users to be targeted from the project owner. For example, in the example shown in Fig. 25, the matching system 1 may acquire affiliation information (production technology) of the target users from the project owner. The matching system 1 may compare the acquired affiliation information with the affiliation information of members registered in the database 21 to set the target range.

[0319] As described below, in order to deliver recommended cases, the matching system 1 utilizes a prediction model that determines targets using a predetermined algorithm. The matching system 1 inputs attribute information and behavioral history information of each user into the prediction model to determine targets. The matching system 1 may also input affiliation information received from the case owner into the prediction model to determine targets.

[0320] Alternatively, the matching system 1 may select users from the database 21 corresponding to the affiliation information received from the project owner without using a prediction model, and deliver recommended projects to the selected users. For example, if the affiliation information is "production technology," the matching system 1 references the "department" column in the member database 122 to identify users who belong to "production technology." The matching system 1 references the project non-disclosure list 1291 and excludes users from companies that are in competition with the project owner from the identified users. In this way, the matching system 1 delivers recommended projects to the selected users.

[0321] The sharing server 100 may set a "project owner member" who is not granted authority as an applicant but is granted authority as a project owner (recruiter). In this case, "project owner" is set as the type of authority in the member data 122.

[0322] [Other Databases] In addition to the various databases 121 to 127 shown in FIG. 2, other databases employed in this embodiment will be described below.

[0323] Fig. 26 is a diagram showing an example of the in-house terminology database 137. As shown in Fig. 26, in-house terminology information is registered for each company ID in the in-house terminology database 137. The sharing server 100 refers to the in-house terminology database 137 to identify in-house terms for each company.

[0324] The internal term information includes affiliation information that can identify the member's affiliation (company and department). The affiliation information is an example of group information that identifies either the company or a department within the company. The affiliation information can also be said to be information that indicates the company and department in which the internal term to be registered is prevalent.

[0325] The in-house term information further includes the "name," "reading," and "meaning" of the term to be registered. For example, in the case of the in-house term "DX," "DX" is registered as the "name," "D-X" is registered as the "reading," and "D-X" is registered as the "meaning."

[0326] Another example of an in-house term is "application development." "Application development" is generally understood to mean developing applications for use on electronic devices such as smartphones. However, in a certain department of a company that handles electronic components, "application development" may mean "developing new uses for components." In such a case, the term "application development" and its meaning (developing new uses for components) are registered in the in-house term database 137.

[0327] FIG. 27 is a diagram showing an example of the profile database 129 and the behavior history database 131. As shown in FIG. 27, the profile database 129 registers the profile information of members (users) by member ID. Some of the profile information may overlap with the information registered in the member database 122. The profile information includes the member's name, age, and gender. Furthermore, the profile information includes affiliation information that can identify the member's affiliation (company and department). The affiliation information is an example of group information for identifying either the company or a department within the company.

[0328] Furthermore, the profile information includes the member's possessed ability information. The member's possessed ability information is categorized by skill, experience, and qualification. These categories correspond to the job recruitment requirements (see FIG. 24). For example, the attribute information for each member is made up of age, gender, affiliation, and possessed ability information. When this member's attribute information for each company is integrated, attribute information for each company is generated.

[0329] 27 , the behavior history database 131 stores behavior history information of members by behavior ID. The behavior history information includes information indicating the behavior of the member in response to information displayed on the screen of the user device 500. The behavior ID is information for identifying each of such behaviors of the member.

[0330] Specifically, the behavior history information includes a member ID, a behavior category, and behavior content. The behavior category includes, for example, a click operation on an information area presented on the screen, a search for information presented on the screen, etc. The behavior content includes, for example, log information consisting of the information area clicked and the time of the click operation. New behavior history information is accumulated in the behavior history database 131 each time the sharing server 100 detects a member's behavior.

[0331] The sharing server 100 links the member's profile information in the profile database 129 with the member's action history information in the action history database 131 .

[0332] Fig. 28 is a diagram showing an example of the case introduction database 132. As shown in Fig. 28, the case introduction database 132 stores recommended case information classified by case ID and a case non-disclosure list 1291.

[0333] The recommended project information includes a project title, a company ID, project content, a major category, a medium category, a minor category, and a display effect. The project owner is identified by the company ID in the recommended project information. The project content includes detailed information such as a project introduction, images related to the project, and videos related to the project. Projects are classified according to the project content. The major category, medium category, and minor category include names corresponding to the classification. The display effect includes a numerical value corresponding to the actions of the user who viewed the project. For example, the display effect includes the average number of clicks on the recommended project information displayed on the screen, the number of times the recommended project is displayed, etc.

[0334] The non-disclosure list 1291 indicates the relationship between the company ID of the project owner and the company IDs (non-disclosure company IDs) of companies to which the project owner does not want their projects to be disclosed. According to the non-disclosure list 1291, company A's projects are prohibited from being disclosed to company C, company B's projects are prohibited from being disclosed to company C, and company C's projects are prohibited from being disclosed to company A. If company A wants to avoid disclosing its projects to companies C and D, 00C and 00D are registered in the non-disclosure company ID column corresponding to company ID = 00A. The sharing server 100 may employ a function that allows the user to set companies to which project disclosure is prohibited by project information (by project ID). The non-disclosure list 1291 is an example of information indicating the competitive relationships among multiple groups.

[0335] The matching system identifies the project owner of the project based on the company ID included in the project information. The matching system 1 uses the project non-disclosure list 1291 to identify companies that are in competition with the project owner. The matching system 1 excludes users who belong to the identified competing companies from the project targets. The matching system 1 also uses the member database 122 to identify users who belong to competing companies.

[0336] The non-disclosure list 1291 is an example of prohibited information that can identify project information that is prohibited from being associated with a user belonging to the first group among multiple project information. The company ID included in the project information is an example of information for identifying the project owner. Note that a member ID may be used instead of a company ID as information for identifying the project owner. The matching system 1 can identify the relationship between the member ID and the company ID by using the member database 122. Note that the open project database 124 shown in Figures 6 and 24 may be provided with the functionality of the project introduction database 132.

[0337] Fig. 29 is a diagram showing an example of the priority database 133. As shown in Fig. 29, priorities are registered in the priority database 133 by priority ID. The priorities include information regarding the priority of the case to be distributed to the user. The priorities include a content algorithm priority, a collaboration algorithm priority, and an integrated priority (final priority). The content algorithm priority, the collaboration algorithm priority, and the integrated priority (final priority) each include a case classification and a priority value.

[0338] The sharing server 100 integrates the case classification and priority value based on the content algorithm priority and the case classification and priority value based on the collaboration algorithm priority, and determines the case classification and priority value based on the integrated priority (final priority).The sharing server 100 uses the case classification and priority value based on the integrated priority (final priority) to determine the case (target case) to be delivered to the user.

[0339] The sharing server 100 calculates the content algorithm priority and the collaboration algorithm priority using the trained prediction model. As shown in Fig. 29, the prediction model is stored in the memory 102 of the sharing server 100. The prediction model is generated by machine learning and is updated by re-learning using the output of the prediction model.

[0340] Known techniques for extracting information highly relevant to a user's preferences from a large amount of information include content-based filtering and collaborative filtering. Generally, content-based filtering is a technique for recommending to a user information that has tags highly relevant to the tags of information the user is browsing. Collaborative filtering is a technique for determining information to recommend to a user based on the browsing history of people with similar preferences to the user. These content-based filtering and collaborative filtering techniques are employed to generate a prediction model according to this embodiment. User attribute information is used as the tag for content-based filtering. This is because recommendations are made based on the similarity of user attribute information. Collaborative filtering, on the other hand, uses user behavior history information. This is because, like general collaborative filtering, recommendations are made based on the user's interests, regardless of the user's attribute information.

[0341] The prediction model includes a content-based algorithm generated based on content-based filtering and a collaboration-based algorithm generated based on collaborative filtering. Note that the prediction model may be generated using any learning method, such as supervised learning or reinforcement learning.

[0342] The sharing server 100 calculates the content algorithm priority by inputting user-specific characteristics (affiliation, skills, age, etc.) into the content-based algorithm. The sharing server 100 calculates the collaboration algorithm priority by inputting the user's behavior history (item browsing history, search history, etc.) into the collaboration-based algorithm.

[0343] [Description of Processing Procedures Related to the Case Information Distribution Function] Next, various processing procedures related to the case information distribution function will be described with reference to Fig. 30 to Fig. 39. Fig. 30 is a flowchart showing processing procedures related to the case information distribution function of the matching system 1.

[0344] 30, first, the sharing server 100 registers the case information in the case introduction database 132 (step Sa1). In step Sa1, the sharing server 100 functions as a case information registration unit.

[0345] Next, the sharing server 100 acquires user information from the profile database 129 (step Sa2). In step Sa2, the sharing server 100 functions as a user information acquisition unit.

[0346] Next, the sharing server 100 sets a priority (content algorithm priority) for the job information based on the user's attribute information (step Sa3). The user's attribute information includes the user's work history. In step Sa3, the sharing server 100 calculates the priority using a content-based algorithm included in the prediction model.

[0347] Next, the sharing server 100 sets a priority (cooperation algorithm priority) for the case information based on the user's behavior history information (step Sa4). In step Sa4, the sharing server 100 calculates the priority using the collaboration-based algorithm included in the prediction model.

[0348] Next, the sharing server 100 weights the attribute-based priority (content algorithm priority) and the behavioral history-based priority (collaboration algorithm priority), integrates the two priorities, and determines the case information to be displayed as recommended cases based on the integrated priority (step Sa5). In step Sa5, the sharing server 100 uses a determination algorithm. In this way, the sharing server 100 associates one or more pieces of case information among the multiple pieces of case information with the user using the attribute information and behavioral history information. The behavioral history information includes information about the user's behavior in relation to the case information.

[0349] A prediction model is configured by the algorithms included in steps Sa3 to Sa5. The prediction model is stored in memory 102 of sharing server 100. Steps Sa3 to Sa5 illustrate a process of inputting attribute information and behavioral history information into a trained prediction model and associating one or more pieces of project information among multiple pieces of project information with users belonging to a certain company (group). The prediction model is trained by machine learning based on the attribute information and behavioral history information.

[0350] Next, the sharing server 100 acquires the determined item information (step Sa6). In step Sa6, the sharing server 100 functions as an item information acquisition unit.

[0351] Next, the sharing server 100 displays the acquired case information as a recommended case on the screen of the user's user device 500 (step Sa7). In step Sa7, the sharing server 100 functions as a display unit.

[0352] Next, the sharing server 100 feeds back the display effect of the item to the item owner (step Sa8). In step Sa8, the sharing server 100 functions as a display effect feedback unit.

[0353] Next, the sharing server 100 learns (relearns) the algorithm (step Sa9). In step Sa9, the sharing server 100 functions as a learning unit. The processor 101 of the sharing server 100 updates the prediction model stored in the memory 102. The prediction model is relearned (retrained) by machine learning based on user attribute information and user behavior history information.

[0354] 31 is a flowchart showing the processing steps of the case information registration unit (Sa1). The case information registration unit accepts a case owner's operation to register case information, and registers the case information in the case introduction database 132 (step Sa11).

[0355] For example, the owner of the project operates the user device 500 to input project information into the user device 500. The user device 500 transmits the input project information to the sharing server 100. The sharing server 100 registers the received project information in the project introduction database 132 in step Sa11.

[0356] Alternatively, the sharing server 100 accepts an operation by the server administrator, and in step Sa11, registers the project information requested by the project owner in the project introduction database 132. In this way, the sharing server 100 registers the project information received from the user device 500 in the project introduction database 132.

[0357] This ends the processing of the case information registration unit. Here, the case information registration unit registers case information including case category information. If the case owner cannot determine the category, a server administrator or the like will support the case owner. Note that in step Sa11, the case information registration unit may register the case information in both the open case database 124 and the case introduction database 132. Furthermore, the open case database 124 may have the functions of the case introduction database 132. In this case, the case information registration unit registers the case information in the open case database 124 in step Sa11.

[0358] 32 is a flowchart showing the processing procedure of the user information acquisition unit (Sa2). The user information acquisition unit acquires user information from the profile database 129 and the behavior history database 131 (step Sa21). The user information acquisition unit acquires user attribute information from the profile database 129 and acquires user behavior history information from the behavior history database 131. The user information acquisition unit executes the above processing for all users. This completes the processing of the user information acquisition unit.

[0359] 33 is a flowchart showing the processing procedure for the content-based algorithm (Sa3). The sharing server 100 executes processing using the content-based algorithm according to the procedure described below. First, the sharing server 100 extracts user attribute information (step Sa31). Next, the sharing server 100 inputs the attribute information into the content-based algorithm (step Sa32).

[0360] Next, the sharing server 100 creates a case priority using a content-based algorithm (step Sa33). The sharing server 100 registers the created case priority as a "content algorithm priority" in the priority database 133. The content algorithm priority includes a case classification and a priority value (see FIG. 29). The sharing server 100 executes the above process for all users. This completes the content-based algorithm process.

[0361] The sharing server 100 may store the created item priority in a cache instead of the priority database 133.

[0362] 34 is a flowchart showing the processing procedure of the cooperation-based algorithm (Sa4). The sharing server 100 executes processing using the cooperation-based algorithm according to the procedure described below. First, the sharing server 100 extracts attribute information of the user (step Sa41). Next, the sharing server 100 inputs the attribute information into the cooperation-based algorithm (step Sa42).

[0363] Next, the sharing server 100 creates a case priority using the collaboration-based algorithm (step Sa43). The sharing server 100 registers the created case priority as a "collaboration algorithm priority" in the priority database 133. The collaboration algorithm priority includes a case classification and a priority value (see FIG. 29). The sharing server 100 executes the above process for all users. This completes the collaboration-based algorithm process.

[0364] The sharing server 100 may store the created item priority in a cache instead of the priority database 133.

[0365] 35 is a flowchart showing the processing procedure of the determination algorithm (Sa5). The sharing server 100 executes processing using the determination algorithm according to the procedure described below. First, the sharing server 100 acquires the content algorithm priority and the collaboration algorithm priority from the priority database 133 (step Sa51).

[0366] Next, the sharing server 100 inputs the content algorithm priority and the collaboration algorithm priority into the decision algorithm (step Sa52). Next, the sharing server 100 uses the decision algorithm to create an integrated case priority (step Sa53). The decision algorithm determines the content and collaboration-based bias, etc.

[0367] Next, the sharing server 100 registers the created item priority as an "integrated priority (final priority)" in the priority database 133. This completes the processing of the decision algorithm.

[0368] The sharing server 100 may store the integrated case priorities in a cache instead of the priority database 133. The sharing server 100 may use either the content-based algorithm or the collaboration-based algorithm to determine the final case priorities instead of using both of them.

[0369] 36 is a flowchart showing the processing steps of the case information acquisition unit (Sa6). First, the case information acquisition unit acquires the final integrated case priority from the priority database 133 (step Sa61). Specifically, the case information acquisition unit acquires the "integrated priority" from the priority database 133.

[0370] Next, the case information acquisition unit acquires case information from the case introduction database 132 (step Sa62). Next, the case information acquisition unit refers to the case non-disclosure list 1291 registered in the case introduction database 132 and excludes cases directed to competing companies (step Sa63).

[0371] More specifically, the project information acquisition unit identifies the company to which the project owner of the project information belongs based on the company ID included in the project information.The project information acquisition unit identifies companies that compete with the company to which the project owner belongs by referring to the project non-disclosure list 1291.The project information acquisition unit identifies the company to which the user to whom the project is to be distributed belongs based on the user's profile information.Based on these identification results, the project information acquisition unit excludes projects that will be distributed to competitors from the large number of project information items that are candidates for display to the user.

[0372] Next, the case information acquisition unit determines, from among the many pieces of case information, the case information to be displayed to the user as a recommended case based on the integrated priority (step Sa64). This completes the processing of the case information acquisition unit.

[0373] 37 is a flowchart showing the processing procedure of the display unit (Sa7). The display unit displays the case information determined by the case information acquisition unit as a recommended case on the screen of the user device 500 of the user (step Sa71). This completes the processing of the display unit.

[0374] 38 is a flowchart showing the processing procedure of the display effect feedback unit (Sa8). First, the display effect feedback unit acquires action history information from the action history database 131 (step Sa81).

[0375] Next, the display effect feedback unit acquires the job information from the job introduction database 132 (step Sa82). Next, the display effect feedback unit calculates an index value of the job display effect (step Sa83). For example, a click-through rate (CTR) may be used as the index value of the job display effect. The CTR is calculated by dividing the number of clicks on the job by the number of times it is displayed.

[0376] Next, the display effect feedback unit registers the index value of the case display effect in the case introduction database 132 (step Sa84). Information regarding the case display effect is used to improve the accuracy of the matching algorithm and to communicate the case display effect to the case owner. Information regarding the case display effect may also include the viewing time of images (including videos) related to the case. Next, the display effect feedback unit displays the index value of the case display effect on the screen of the case owner's user device 500 (step Sa85). This completes the processing of the display effect feedback unit.

[0377] 39 is a flowchart showing the processing steps of the learning unit (Sa9). First, the learning unit accesses the profile database 129 and the case introduction database 132 to acquire information (attribute information and behavior information) of all users and case information (step Sa91). Next, the learning unit acquires parameter information of the algorithms (content-based algorithm and collaboration-based algorithm) from the prediction model (step Sa92).

[0378] Next, the learning unit updates the parameter information of the algorithm (step Sa93). Before learning by the learning unit, hyperparameters are used as parameters of the algorithm. The values ​​of the hyperparameters of the algorithm may be determined by another learning algorithm such as deep learning. Furthermore, even for parameters other than hyperparameters, the parameter values ​​may be updated manually by a person without relying on a learning algorithm such as deep learning.

[0379] Next, the learning unit learns the algorithm based on the index value of the item display effect, etc. (step Sa94). Next, the learning unit stores the learned algorithm in the memory 102 of the sharing server 100 as an updated prediction model (step Sa95). This completes the processing of the learning unit.

[0380] Although the example described here uses a predictive model trained by machine learning to determine the items to be distributed to users, the sharing server 100 may instead determine the items to be distributed to users based on rules defined by a program created by a person, without using such a predictive model.

[0381] As described above, the matching system 1 has a function of delivering recommended jobs by effectively utilizing a platform that matches recruiters and applicants. In particular, the matching system 1 can analyze user information based on the user's attribute information and user behavior history information, and provide the user with jobs that match the user. The matching system 1 can also limit the scope of job disclosure.

[0382] This allows the distribution of recommended cases to be narrowed down to specific companies, specific industries, or specific groups. Furthermore, the matching system 1 ensures the reliability of information about the companies to which the user belongs, making it possible to distribute recommended cases with greater accuracy. Furthermore, the matching system 1 can feed back the display results of recommended cases to the algorithm, improving the accuracy of the matching algorithm. As a result, the matching system 1 can effectively distribute recommended cases to users.

[0383] [Explanation of Processing Procedures Related to Index Function] Next, various processing procedures related to the index function will be described with reference to Fig. 40 to Fig. 43. Fig. 40 is a flowchart showing the processing procedures related to the index function of the matching system 1.

[0384] In the flowchart shown in Figure 40, first, the sharing server 100 registers in-house terms in the in-house terminology database 137 (step Sw1). In step Sw1, the sharing server 100 functions as an in-house terminology registration unit. Next, the sharing server 100 registers a recruitment request in the recruitment request database 124 (step Sw2). In step Sw2, the sharing server 100 functions as a request registration unit. When registering a recruitment request in the recruitment request database 124, the request registration unit indexes in-house terms included in the recruitment request information.

[0385] Next, the sharing server 100 displays the indexed case information on the user device 500 (step Sw3). For example, if an in-house term is used in a sentence explaining the details of the case, the sentence is displayed on the user device 500 with the in-house term underlined. Instead of or in addition to underlining the in-house term, the in-house term may be displayed on the screen 552 of the user device 500 in a different color from the other words. In step Sw3, the sharing server 100 functions as a display unit.

[0386] FIG. 41 is a flowchart showing the processing steps of the in-house terminology registration unit (Sw1). First, a company employee compiles in-house terminology by using their company's system or the like (step Sw11). In other words, the employee creates something like an in-house glossary. Next, the employee downloads a registration template from the sharing server 100 (step Sw12). Next, the employee enters the necessary information into the template (step Sw13). The necessary information includes the in-house terminology, its meaning, and its meaning.

[0387] Next, the company representative accesses the sharing server 100 and obtains the representative's own profile information from the profile database 129 (step Sw14). The profile information includes the company ID of the company to which the representative belongs. The representative uploads the profile information and a template to the matching system 1 (step Sw15). The sharing server 100 obtains the profile information and the template. The sharing server 100 generates in-house terminology information based on the obtained profile information and template, and registers the generated in-house terminology information in the in-house terminology database 137 (step Sw16). As a result, in-house terms and their meanings are registered in the in-house terminology database 137. In-house terms and their meanings are also registered by company in the in-house terminology database 137.

[0388] The processing of steps Sw11 to Sw16 is executed for each company. As a result, in-house terminology information is registered for each company in the in-house terminology database 137. Note that the sharing server 100 may also register in-house terms collectively in the in-house terminology database 137 from an external file such as a CSV (Comma Separated Value) file.

[0389] 42 is a flowchart showing the processing steps of the job registration unit (Sw2). First, a recruiter who wishes to register a job in the system accesses the profile database 129 to obtain his / her company information (step Sw21). Next, the recruiter inputs the job information into the user device 500 (step Sw22). The job information includes various information such as the job content registered in the job database 124. The recruiter may input details of the job content using in-house terminology commonly used in the company to which the recruiter belongs.

[0390] Next, the sharing server 100 automatically searches for in-house terms included in the input job information (step Sw23). At this time, the sharing server 100 indexes the in-house terms found by the search and links them to in-house terminology information registered in the in-house terminology database 137. Next, the sharing server 100 registers the job information input by the recruiter in the recruiting job database 124 (step Sw24). As a result, the job information is registered in the recruiting job database 124 with the in-house terms and their meanings associated with each other.

[0391] 43 is a flowchart showing the processing procedure for displaying the meaning of company terminology on the screen in response to an applicant's operation. Here, we will explain the processing for providing a matching job that suits the applicant, taking into consideration the disclosure scope of the job and the applicant's side job capacity, and for informing the applicant of the meaning of company terminology as needed.

[0392] First, the sharing server 100 receives a search request for a job posting from an applicant (step Sw101). Next, the sharing server 100 determines the applicant's affiliation (step Sw102). The details of this process have already been described as step S1451.

[0393] Next, the sharing server 100 extracts projects that can be disclosed (step Sw103). Details of this process have been explained as step S1452. Next, the sharing server 100 extracts projects that can be handled with the applicant's spare capacity for a side job (step Sw104). Details of this process have been explained as step S1453. Note that the process of step Sw104 may be deleted from this flowchart. In other words, the sharing server 100 may extract projects that match the applicant without taking into account the applicant's spare capacity for a side job.

[0394] Next, the sharing server 100 extracts a matching case (step Sw105). Details of this process have been described as step S1454. Next, the sharing server 100 transmits the matching case (step Sw106). Details of this process have been described as step S1455. In this way, the sharing server 100 transmits the matching case to the applicant device 300, thereby displaying the matching case on the applicant device 300.

[0395] Next, the sharing server 100 detects a click operation on an in-house term corresponding to the registered index (step Sw107). Next, the sharing server 100 references the in-house terminology database 137 and transmits the meaning of the in-house term to the applicant device 300 (step Sw108). Next, the applicant device 300 displays the meaning of the in-house term on the display 305 (step Sw109). As a result, for example, the screen 552 shown in FIG. 1 is displayed on the display 305. In this way, the sharing server 100 transmits the meaning of the in-house term to the applicant device 300, thereby displaying the meaning of the in-house term on the applicant device 300.

[0396] As described above, this embodiment provides a matching system 1 that functions as a crowdsourcing platform. To use crowdsourcing to find more suitable talent, it is desirable to broaden the scope of crowdsourcing beyond a specific company or a small number of companies. In this case, it becomes necessary to consider the conflict of interest between the recruiter seeking contractors and the applicants applying for the job. In this embodiment, the sharing server 100 communicates with the applicant device 300, operated by the applicant, via the communication interface 104. The sharing server 100 registers in the database the business information for which contractors are being recruited and disclosure information indicating the scope of disclosure of the business information (step S1442). Based on the disclosure information, the sharing server 100 determines, from the business information registered in the database 120, which business information is permitted to be disclosed to the applicant (step S1452). The business information includes detailed information about the business content (job content (recruitment guidelines)). The sharing server 100 displays on the applicant device 300 the business information that is permitted to be disclosed to the applicant and the meanings of terms (in-house terms including company terms) included in the detailed information (steps Sw3, Sw106, Sw109).

[0397] Therefore, according to this embodiment, it is possible to select an appropriate applicant taking into consideration the interests of the recruiter and the applicant. Furthermore, according to this embodiment, it is possible to prevent applicants from misunderstanding the content of the business information due to terms that are unfamiliar to them or that are used in a different way than usual.

[0398] Furthermore, according to this embodiment, users can reduce the effort required to provide supplementary explanations of in-house terminology when exchanging information about a project with users outside the company. Furthermore, the sharing server 100 can automatically index in-house terminology contained in project information. Therefore, users do not need to manually index in-house terminology. Furthermore, the sharing server 100 has a function for registering in-house terminology in the in-house terminology database 137. Therefore, users do not need to manually register in-house terminology in the in-house terminology database 137. Furthermore, users can recognize that in-house terminology is not understood by other companies, and can therefore understand cultural differences with other companies.

[0399] In this embodiment, "company terms" for a company are cited as an example of "in-house terms" that are prevalent in the group to which the user belongs. However, instead of or in addition to "company terms," ​​the embodiments described so far may also be applied to terms similar to company terms used in non-profit organizations, communities, and units (departments, sections, etc.) within those organizations.

[0400] In the present embodiment described above, a "company group" and a "departmental group within the same company" are examples of a "group." Applicants who do not belong to a company, such as freelancers, may also form a "group." A "company group" may also be formed by multiple companies.

[0401] In this embodiment, a "company forming a community relationship" is an example of a "community group."

[0402] As described above, the sharing server 100 communicates with a plurality of user devices 500, including user devices 500 operated by users belonging to a first group (one of companies A, B, C, etc.), via the communication interface 104. The sharing server 100 accesses a database 120 (profile database 129, case introduction database 132) in which group information (user affiliation information) capable of identifying each of the plurality of groups, a plurality of case information, and prohibition information (case non-disclosure list 1291) capable of identifying case information that, among the plurality of case information, is prohibited from being associated with a user belonging to the first group. The sharing server 100 associates one or more of the plurality of case information with users belonging to the first group (step Sa64), and distributes the one or more pieces of case information to the first user device based on the association (step Sa71). The sharing server 100 excludes the case information for which association is prohibited by the prohibition information, and associates the case information with the users belonging to the first group (step Sa63).

[0403] To find more suitable talent using crowdsourcing, it is desirable to broaden the scope of crowdsourcing beyond a specific company or a small number of companies. In this case, it becomes necessary to consider the conflict of interest between the recruiter seeking contractors and the applicants applying for the job. In this embodiment, the recruiter device 200 transmits to the sharing server 100 business information for which contractors are sought and disclosure information indicating the scope of disclosure of the business information. The sharing server 100 registers the business information together with the disclosure information in the database 120. The sharing server 100 determines, based on the disclosure information, which business information registered in the database 120 is permitted to be disclosed to applicants, and provides the business information permitted to be disclosed to the applicant device 300. Therefore, this embodiment makes it possible to select appropriate applicants taking into consideration the conflict of interest between the recruiter and applicants.

[0404] In the present embodiment described above, a "company group" and a "departmental group within the same company" are examples of a "group." Applicants who do not belong to a company, such as freelancers, may also form a "group." A "company group" may also be formed by multiple companies.

[0405] In this embodiment, a "company forming a community relationship" is an example of a "community group."

[0406] In this embodiment, the information of "non-disclosure targets" included in the disclosure information is an example of "information that can identify targets to whom disclosure of business information is prohibited."

[0407] The communication (S9 in FIG. 11) for transmitting approval information from the applicant device 300 of the manager who functions as the approver to the approval unit 147 is performed on a logical communication path identified by the member ID of the approver. "The approval unit 147 receiving the approval information on such a communication path" is an example of "receiving an approval notification in communication involving the identification information of the approver of the first applicant."

[0408] In this embodiment, the "applicant evaluation summary" registered in the evaluation summary database 127 is an example of "evaluation information based on evaluations received from the recruiter device 200 functioning as an evaluator device." In this embodiment, the "recruiter evaluation summary" registered in the evaluation summary database 127 is an example of "evaluation information based on evaluations received from the applicant device 300 functioning as an evaluator device."

[0409] 9 merely shows an example of data registered in the evaluation summary database 127. In this embodiment, it is also assumed that a member belonging to company A, in the position of an applicant, evaluates members belonging to companies A, B, C, ... and acting as recruiters. In this embodiment, it is also assumed that a member belonging to company B, in the position of an applicant, evaluates members belonging to companies A, B, C, ... and acting as recruiters. In this embodiment, it is also assumed that a member belonging to company A, in the position of a recruiter, evaluates members belonging to companies A, B, C, ... and acting as applicants. In this embodiment, it is also assumed that a member belonging to company B, in the position of a recruiter, evaluates members belonging to companies A, B, C, ... and acting as applicants.

[0410] In this embodiment, the "recruiter device 200A" operated by a recruiter belonging to company A functions as an evaluator device and is an example of a "first evaluator device (recruiting-side first evaluation device) operated by one or more evaluators belonging to a first group." In this embodiment, the "applicant device 300A" operated by an applicant belonging to company A functions as an evaluator device and is an example of a "first evaluator device (applicant-side first evaluation device) operated by one or more evaluators belonging to a first group."

[0411] In this embodiment, the "recruiter device 200B" operated by a recruiter belonging to company B functions as an evaluator device and is an example of a "second evaluator device (recruiting-side second evaluation device) operated by one or more evaluators belonging to a second group different from the first group." In this embodiment, the "applicant device 300B" operated by an applicant belonging to company B functions as an evaluator device and is an example of a "second evaluator device (applicant-side second evaluation device) operated by one or more evaluators belonging to a second group different from the first group."

[0412] 21 illustrates a systems department and a planning department as examples of departments of company B. In this embodiment, "one of the systems department and the planning department" is an example of a "first divided group" included in the first group, and the other is an example of a "second divided group" included in the first group.

[0413] Sharing server 100 extracts from the list in job posting database 124 job information for which the applicant's working hours do not exceed the upper limit hours based on the estimated man-hours registered in job posting database 124, the upper limit hours for side jobs registered in company database 121, the actual hours for side jobs registered in side job database 125, and the expected hours for side jobs registered in side job database 125. Specifically, for example, if the applicant is engaged in multiple side jobs, sharing server 100 calculates the sum of the actual hours for side jobs corresponding to each side job to determine the total actual hours for side jobs, and calculates the sum of the expected hours for side jobs corresponding to each side job to determine the total expected hours for side jobs.

[0414] The sharing server 100 calculates the total side job hours by adding the calculated total actual side job hours to the calculated total expected side job hours. The sharing server 100 calculates the applicant's available side job hours by subtracting the total side job hours from the applicant's maximum side job hours. The sharing server 100 searches the list of available side job database 124 for jobs that can be handled with the calculated available side job hours.

[0415] At this time, the sharing server 100 calculates the time required to respond to each job posting based on the estimated man-hours in the job posting database 124, and searches for job postings that fall within the range of available side job time. Here, the "side job upper limit time" is an example of "upper limit time that is the upper limit of the applicant's working hours," the "actual side job time" is an example of "actual time that is the time the applicant has already worked," and the "expected side job time" is an example of "expected working hours of the applicant." The upper limit time is not limited to the side job, but can also be the time that sets an upper limit on the total time for the main job and the side job.

[0416] The first upper limit time may not be the upper limit time for the side job, but may be the upper limit time for all work including the main job and the side job. The first actual time and the first expected time may be the total time for all work including the side job and the main job, not just the time for the side job.

[0417] The recruiter device 200 and the applicant device 300 may not only be equipped with all of the processor, memory, communication interface, and input / output interface shown in FIG. 2, but may also be a thin client system using VDI (Virtual Desktop Infrastructure). A thin client system using VDI is a system in which a desktop environment on a server is transferred to a terminal in a remote location for use. The recruiter device 200, applicant device 300, and sharing server 100 do not necessarily have to be independent devices. When using a thin client system such as the one described above, the functions of the recruiter device 200, applicant device 300, and sharing server 100 can be provided on the same aggregation server.

[0418] The database 120 is not limited to a relational database, and an object-type or NoSQL-type database may also be used.

[0419] The sharing server 100 is an example of a computing device. The computing device may be configured by a server (on-premise server, cloud server, etc.), a serverless system, etc. Here, an on-premise server is a server installed and managed in facilities managed within a company. A cloud server is a server (rented server) provided by another business via a network. A serverless system is a system in which computing and memory functions can be used only when necessary, without being aware of the existence of a server. Computing devices include servers and serverless systems. Servers include on-premise servers and cloud servers.

[0420] <Modification 1> Next, Modification 1 will be described with reference to Figures 44 to 46. In Modification 1, a counter offer function will be described that allows a recruiter to encourage selected members from among a large number of members to participate in the recruiting business.

[0421] [Background for proposing the counter-offer function] In crowdsourcing, recruiters generally disclose information about job openings and wait for applications from those who are interested in the content of the job. However, with this recruitment method, it may take a long time for applicants to respond. Also, it is unclear whether applications will come from people with the skills the recruiter is looking for.

[0422] Therefore, it is conceivable that the recruiter would search for members and nominate a suitable member (a counteroffer). However, if the recruiter is only informed of the member ID and the member's name, it is difficult for the recruiter to nominate the applicant they truly desire. Furthermore, to prevent confidential information from being leaked to rival companies, etc., the search results must exclude member information of rival companies, etc.

[0423] In light of this background, in Variation 1, search results including detailed member profile information are provided to recruiters who perform member searches. Furthermore, in Variation 1, member information of companies that are rivals to the recruiter's company is excluded from the search results. Variation 1 will be explained in detail below using the drawings.

[0424] FIG. 44 is a diagram for explaining the functions of the sharing server 100, the recruiter device 200, and the applicant device 300 according to the first modification.

[0425] 44, the sharing server 100 functionally includes, in addition to the member search unit 143, a counter offer request unit 161, a counter offer approval request unit 162, and a counter offer request acceptance notification unit 163. These various functions are realized by the processor 101, memory 102, storage 103, and communication interface 104 that the sharing server 100 includes.

[0426] As already explained, the member search unit 143 has a function to search for members of the matching system 1. In particular, in variant example 1, the member search unit 143 has a function to provide detailed profile information of members to a searcher. When the recruiter's search operation is accepted, the recruiter device 200 executes a member search process (step S21). In particular, in step S21, the recruiter device 200 accepts a search operation for the recruiter to make a counter offer. The member search unit 143 provides the recruiter device 200 with information on members registered in the member database 122. The provided member information includes detailed profile information of members. However, the member search unit 143 excludes member information of companies, etc. that are rivals to the recruiter's company, etc., from the search results.

[0427] The recruiter device 200 receives the member information (search results) from the member search unit 143 and displays the member information as the search results on the display 205 (step S22). The recruiter device 200 then accepts an operation by the recruiter to select an applicant from the search results. That is, the recruiter selects a member to whom to make a counteroffer based on the search results and makes the counteroffer by operating the recruiter device 200 (step S23). The recruiter device 200 transmits the member ID of the member to whom the counteroffer is to be made to the sharing server 100.

[0428] The counter offer request unit 161 receives the member ID of the member who is the target of the counter offer from the recruiter device 200. The counter offer request unit 161 identifies the member corresponding to the received member ID. The counter offer request unit 161 notifies the applicant device 300 of the member who is the target of the counter offer that a request for a counter offer has been received. This notification may include information about the recruitment job that is the target of the counter offer. The member who is the target of the counter offer receives the request for a counter offer via the applicant device 300. The "request" received here is an example of "information encouraging an applicant to apply." The member who is the target of the counter offer decides whether to accept the request for a counter offer. The member who is the target of the counter offer can use the applicant device 300 to perform an operation to accept the request for a counter offer or an operation to reject the request for a counter offer. The applicant device 300, for example, accepts the request for a counter offer (step S24). The applicant device 300 that has accepted the request for a counter offer transmits the application information to the counter offer approval request unit 162 .

[0429] The counter offer approval request unit 162 sends the subordinate's application information to the applicant's superior. The counter offer approval request unit 162 identifies the member ID of the applicant's superior, who is the applicant's manager, based on the relationship between the applicant's member ID and the superior's member ID registered in the member database 122. The applicant's superior checks the application information on his or her own applicant device 300 and approves the application (step S25).

[0430] The counter offer request acceptance notifying unit 163 receives approval information from the applicant's superior. The counter offer request acceptance notifying unit 163 accepts the applicant's application on the condition that the approval information has been received. The counter offer request acceptance notifying unit 163 notifies the recruiter device 200 that the application from the member who made the counter offer has been accepted. Based on the notification, the recruiter device 200 notifies the recruiter that the counter offer has been accepted (step S26). More specifically, the recruiter device 200 displays information on the display 205 to notify the recruiter that the counter offer has been accepted.

[0431] Fig. 45 is a diagram showing an example of a member database 122A according to Modification 1. Compared to the member database 122 shown in Fig. 4, the member database 122A shown in Fig. 45 has added profile information and profile disclosure information indicating whether or not the profile is to be made public.

[0432] Matching system 1 gives members the authority to register and modify their own profile information in member database 122A using applicant device 300. Members register various pieces of their own profile information in member database 122A using applicant device 300. The profile information includes, for example, the member's Synthetic Personality Inventory (SPI) information, the member's work history, the member's achievements, the member's qualifications, etc.

[0433] Members set public profile information using the applicant device 300. The profile information of members whose profile information is set to "allowed" is provided to searchers. The profile information of members whose profile information is set to "disallowed" is not provided to searchers. The sharing server 100 registers the public profile information in the member database 122A based on the settings selected by each member. In this way, the sharing server 100 accepts input from each of multiple members of information indicating whether or not they permit their profile information to be included in search results.

[0434] Here, an example has been described in which whether or not a member's profile information is permitted to be made public is determined based on the profile public information setting. However, the sharing server 100 may also accept a setting operation for whether or not to permit disclosure for each type of profile information. This allows, for example, a member to make achievements and qualifications public, while keeping SPI information private. Alternatively, if the profile information includes age, the member can keep age private and make other profile information public. In this case, the sharing server 100 registers multiple pieces of profile information for each of multiple registrants (members) in the member database 122A. The sharing server 100 accepts input from each of the multiple registrants to set the range of the multiple pieces of profile information to be made public as search results.

[0435] 46 is a flowchart showing the processing steps of a reverse offer member search process according to Modification 1. The processing based on this flowchart is executed by the sharing server 100.

[0436] First, the sharing server 100 receives a search request from a searcher to search for members suitable for a recruitment request (step S211). Here, the searcher is a recruiter who has a recruitment request. The recruiter uses his / her own recruiter device 200 to search for members who have skills suitable for the recruitment request. The recruiter's search request is received by the sharing server 100 in step S211. The search request may include the searcher's member ID and the request ID of the recruitment request.

[0437] Next, the sharing server 100 identifies the company to which the searcher belongs from the member database 122A and the company database 121 (step S212). Next, the sharing server 100 identifies the community to which the searcher belongs from the community database 123 (step S213).

[0438] Next, the sharing server 100 identifies the disclosure level and non-disclosure company ID list of the recruitment request registered in the recruitment request database 124 (step S214). Next, the sharing server 100 extracts members who can disclose to the searcher (step S215).

[0439] More specifically, the sharing server 100 identifies companies that should not disclose the recruitment opportunities held by the searcher (recruiter) based on the non-disclosure company list and disclosure level in the recruitment opportunity database 124. The sharing server 100 determines members belonging to such companies as members who cannot be disclosed to the searcher. The sharing server 100 extracts members other than those belonging to such companies as members who can be disclosed to the searcher.

[0440] Next, the sharing server 100 refers to the member database 122A and excludes the profile information of members whose profile information is set to non-disclosure from the extracted member information (step S216).

[0441] Next, the sharing server 100 transmits the extracted member information to the search request source (step S217), and the processing based on this flowchart ends. The recruiter device 200 that made the search request receives the member information transmitted from the sharing server 100 and displays the information on the display 205. The information displayed on the display 205 displays the ID, name, and profile information of each extracted member. However, for members whose profile information has not been disclosed, only the member's ID and name are displayed, and no profile information is displayed.

[0442] As explained above, according to the first modification, a recruiter can refer to detailed member profile information to search for members who are considered most suitable to apply for the job and make a counteroffer to those members. Furthermore, members from companies that are rivals to the recruiter's company or community are excluded from the members displayed as search results. This prevents the recruiter from placing an order with members from such rival companies. Furthermore, because members themselves can decide whether or not to make their profile information public, a system can be provided that respects the free will of each member.

[0443] In addition to the profile information, members may be able to set whether or not to make their name public. Also, several categories of profile information may be provided, and members may be able to set whether or not to make their profile information public for each category.

[0444] By adding the offer function described above to the matching system 1, recruiters can check the profile information of members who are permitted to view the recruitment project. Furthermore, recruiters can encourage applications from members with whom they wish to place orders. Members who are encouraged to apply by recruiters can view the project information and accept or reject the application. Furthermore, when registering or editing member information, each member can decide whether or not to make their profile information public. This allows recruiters to actively select recipients of offers and quickly put the most suitable applicants to work.

[0445] <Modification 2> Next, Modification 2 will be described with reference to Figures 47 to 51. In Modification 2, a member group application function will be described, which allows a plurality of members to apply for a recruitment operation as a group.

[0446] [Background for proposing a member group application function] In crowdsourcing, typically, a recruiter discloses information about a job posting, and individuals who are interested in the content of the posting apply for that posting. However, there are many jobs that require or are preferable to be handled by a team of multiple people, such as comprehensive tasks ranging from business planning to acquiring intellectual property rights related to the project. For this reason, if the number of people recruited is limited to one, it is difficult for those seeking orders to take on more work than they can handle individually.

[0447] In view of this background, Modification 2 provides a member group application function that allows multiple members to apply for recruitment services as a group. Modification 2 will be described in detail below.

[0448] Fig. 47 is a block diagram showing the configurations of the sharing server 100, recruiter device 200, and applicant device 300 according to Modification 2. The block diagram shown in Fig. 47 adds a member group database 128 to the block diagram shown in Fig. 2. The recruiting request database 124A shown in Fig. 47 adds a function to the recruiting request database 124 shown in Fig. 6 that enables registration of recruiting requests that allow applications from member groups.

[0449] Member groups consisting of multiple members are registered in the member group database 128. Using the recruiter device 200, the recruiter can register in the recruiting job database 124A a job that allows applications by a member group. Using the applicant device 300, the applicant can apply for a job that allows applications by a member group using a member group registered in the member group database 128.

[0450] 48 is a diagram showing an example of a member group database 128 relating to Modification 2. Information about member groups is registered in the member group database 128. The information about member groups includes a group ID for identifying the member group, the company ID of the company to which each member of the member group belongs, and the member ID of each member of the member group.

[0451] Hereinafter, the member groups corresponding to each group ID may be referred to as member group G1, member group G2, member group G3, etc. using the group ID.

[0452] Member group G1 is made up of three members identified by member IDs P1, P2, and P5. The company ID registered for member group G1 is 00A, so it can be seen that all three members belong to company A.

[0453] Member group G2 is made up of two members identified by member IDs P1 and P3. The company IDs registered corresponding to member group G2 are 00A and 00B, so it can be seen that one of the two members belongs to company A and the other to company B. As can be seen by comparing member group G1 and member group G2, member ID P1 is registered in both member groups G1 and G2. Therefore, member P1 belongs to two member groups.

[0454] Member group G3 is made up of four members identified by member IDs P4, P7, P8, and P14. The company ID registered for member group G3 is 00C, so it can be seen that all four members belong to company C.

[0455] The member group database 128 is stored in the storage 103 of the sharing server 100, as shown in Figure 47. A member forms a member group with the consent of other members they have met through the same company or community, etc., and registers the member group in the member group database 128. A "member group" is an example of an "application group."

[0456] Fig. 49 is a diagram showing an example of the recruiting request database 124A related to Modification 2. Compared to the recruiting request database 124 shown in Fig. 6, the recruiting request database 124A shown in Fig. 49 has added information on the recruiting type. The recruiter operates the recruiter device 200 to set the recruiting type. The sharing server 100 associates the recruiting type based on the setting with the business information and registers it in the recruiting request database 124A.

[0457] Recruiters can select the recruitment type from group and individual. If the recruiter does not select a recruitment type, the recruitment type of the job is considered to be not limited to either group or individual. Jobs with a recruitment type set to group can only be accepted by member groups. Jobs with a recruitment type set to individual can only be accepted by individual members. Jobs with no recruitment type restrictions can be accepted by either member groups or individuals. "Recruitment type information" is an example of "information that can identify that the job for which contractors are being recruited is a job that should be applied for jointly by multiple recruiters."

[0458] Figure 50 is a diagram for explaining the functions of the sharing server 100, recruiter device 200, and applicant device 300 according to Modification 2. In Figure 50, compared to Figure 11, a determination unit 145A is added to the sharing server 100. Also, compared to Figure 11, in Figure 50, step S7A is added after step S7, and group application step S8A is adopted instead of application step S8.

[0459] In this example, it is assumed that the applicant belongs to multiple member groups. The applicant operates the applicant device 300 to search for the recruitment job (step S6). The applicant device 300 transmits a search request to the job extraction unit 145 of the sharing server 100.

[0460] When the case extraction unit 145 receives a search request, it extracts cases that the applicant is allowed to view from among the recruitment cases registered in the recruitment case database 124, as explained using FIG. 11 . The cases extracted by the case extraction unit 145 include cases where the recruitment type is either "group," "individual," or "unlimited." The case extraction unit 145 transmits the extracted recruitment cases to the applicant device 300. The applicant device 300 receives the recruitment cases from the case extraction unit 145. The applicant device 300 displays the received recruitment cases on the display 305 (step S7).

[0461] The display 305 displays the disclosure level, project title, estimated man-hours, estimated period, project content, recruitment type, etc. for each solicited project. If the applicant wishes to apply as a member group, the applicant uses the operation unit 306, such as a mouse and keyboard, to specify the member group and select a project for which the recruitment type is set to "group" or "unlimited." The applicant device 300 accepts the member group and the project for which the applicant wishes to apply based on the applicant's operation (step S7A). The applicant device 300 transmits the group ID of the accepted member group and the project ID of the accepted project to the sharing server 100. The determination unit 145A of the sharing server 100 acquires the group ID and the project ID.

[0462] The determination unit 145A accesses the member group database 128 and identifies the member ID registered in correspondence with the acquired group ID. The determination unit 145A accesses the member database 122 and identifies the company ID corresponding to the identified member ID.

[0463] The determination unit 145A accesses the community database 123 and identifies the community ID of the community to which the company with the identified company ID belongs. The determination unit 145A accesses the solicited project database 124A and identifies the company ID (the company ID of the recruiter), non-disclosure company ID, disclosure level, and solicitation type registered in correspondence with the acquired project ID.

[0464] Based on the information identified as described above, the determination unit 145A determines whether the recruitment request accepted by the applicant device 300 is a request that is permitted for application by the member group designated by the applicant. In other words, the determination unit 145A determines whether or not to permit application by the member group.

[0465] For example, if one of the members in the member group belongs to a company that is listed on the non-disclosure company ID list corresponding to the job posting, the determination unit 145A will not allow the member group to apply. Alternatively, if one of the members in the member group belongs to a company outside the community even though the disclosure level of the job posting is "within the community," the determination unit 145A will not allow the member group to apply.

[0466] The determination unit 145A returns the determination result to the applicant device 300. Figure 50 shows the flow when the determination unit 145A permits the application by the member group. If the determination unit 145A permits the application by the member group, the applicant device 300 accepts the application by the member group (step S8A). For example, the applicant device 300 displays on the display 305 a screen indicating that the application accepted in step S7A is permitted and a screen asking the applicant whether or not to apply. The applicant selects to apply using the operation unit 306, such as a mouse and keyboard.

[0467] When the applicant device 300 receives an application from a member group (step S8A), it transmits the application information to the sharing server 100. The application unit 146 of the sharing server 100 acquires the application information. The subsequent processing is the same as that described using FIG. 11 . However, the application unit 146 transmits the application information to the superiors of each member belonging to the member group. Therefore, the application approval processing of step S9 is executed for each superior of each member belonging to the member group. Therefore, the approval unit 147 receives approval information indicating that the subordinate's application is approved, or rejection information indicating whether the subordinate's application is rejected, from multiple superiors.

[0468] The approval unit 147 accepts an applicant's application only when approval information has been obtained from all of the superiors of each member belonging to the member group. Having accepted the applicant's application, the approval unit 147 transmits the application information to the recruiter device 200. As already explained using FIG. 11 , the recruiter device 200 displays the application details on the display 205 (step S10). The recruiter inputs the result of the decision on whether to hire or reject the applicant to the recruiter device 200. The recruiter device 200 accepts the input result (step S11) and transmits the accepted result of hire or rejection to the notification unit 148 of the sharing server 100.

[0469] The notification unit 148 transmits the application result (result of whether the applicant was hired or not) to the applicant device 300 of the applicant and the applicant's superior (manager) device 300. However, the notification unit 148 transmits the application result to the superior of each member belonging to the member group.

[0470] The applicant's device 300 and the applicant's device 300 of the superior of each member belonging to the member group display the application results on the display 305 (steps S12 and S13). The applicant and the superior of each member belonging to the member group can check the application results by looking at the display 305.

[0471] 51 is a diagram for explaining the procedure for registering a recruitment request related to Modification 2 in the recruitment request database 124A. In FIG. 51, compared to FIG. 14, a recruitment type is added to the business information input to the recruiter device 200.

[0472] In the second modification, when a recruiter registering a recruitment request inputs business information and disclosure information for the recruitment request into the recruiter device 200, the recruiting type of the recruitment request can be included in the business information. The recruitment type is either group or individual. The request registration unit 144 of the sharing server 100 registers the recruitment request, including the recruitment type selected by the recruiter, in the recruitment request database 124A (step S1442). If the recruiter does not select a recruitment type, the request registration unit 144 registers information indicating that the recruitment type is not limited in the recruitment request database 124A. The other content shown in FIG. 51 is the same as that already described in FIG. 14, and therefore the description thereof will not be repeated here.

[0473] As explained above, according to Variation 2, multiple members can apply for a job as a group. Moreover, according to Variation 2, whether or not to approve an application from a member group is determined based on the relationship between the company and community to which the recruiter belongs and the companies and communities to which each member of the member group belongs. This prevents a member group that includes a member who belongs to an organization that is in competition with the applicant from accepting the job from that applicant.

[0474] By adding the member group application function described above to the matching system 1, it is possible to provide a system in which the order-receiving party can view job postings and apply for the job postings as a member group. This makes it possible for the matching system 1 to handle orders for large-scale work that is best done by a team.

[0475] <Modification 3> Fig. 52 is a diagram showing the configuration of a matching system 1A according to Modification 3. As shown in Fig. 52, the functions of the sharing server 100 may be distributed among systems within each company. That is, instead of the centralized management type matching system 1, a decentralized management type matching system 1A may be adopted as the matching system 1.

[0476] The system configuration shown in Fig. 52 is common to companies A, B, C, D, etc. Each company is provided with a user device 500, a database 520, and a storage 503 for storing the database. When a member operates the user device 500 as a recruiter, the user device 500 functions as a recruiter device 200. When a member operates the user device 500 as an applicant, the user device 500 functions as an applicant device 300.

[0477] The user device 500 is configured, for example, by a server. The user device 500 is an example of a computing device that includes the recruiter device 200 and the applicant device 300. Like the recruiter device 200 and the applicant device 300, the user device 500 includes a processor, a memory that stores programs and the like necessary for the processor's arithmetic processing, a communication interface, and the like.

[0478] Database 520 has the functions of database 120 shown in Fig. 2 and includes a job posting database 524 that replaces job posting database 124, as well as various other databases. Job postings proposed by employees of company A as recruiters are registered in company A's job posting database 524. Job postings proposed by employees of company B as recruiters are registered in company B's job posting database 524. Similarly, job postings proposed by employees of each company as recruiters are registered in other companies' job posting databases 524.

[0479] A disclosure permission list 521 is registered in the database 520. The disclosure permission list 521 includes a list of groups (companies, communities, etc.) that are permitted to disclose job openings. The disclosure permission list 521 includes information corresponding to the "non-disclosure company ID list" and "disclosure level" among the information registered in the job opening database 124 shown in FIG. 6. The user device 500 registers the job openings (business information) and the disclosure permission list 521 (disclosure information) that indicates the disclosure range of the job openings in the database 520.

[0480] The user device 500 of company A determines which companies or communities to disclose the recruitment opportunity to and which companies or communities not to disclose the recruitment opportunity to, based on the disclosure permission list 521. The user device 500 of company A transmits the recruitment opportunity to each company or community based on the determination. For example, if the user device 500 of company A determines to disclose a recruitment opportunity to company C but not to companies B and D, it transmits the recruitment opportunity to company C but does not transmit the recruitment opportunity to companies B and D.

[0481] Like the user device 500 of company A, the user device 500 of each of companies B, C, D, and so on operates based on the disclosure permission list 521. In this way, the user device 500 determines, from among the recruitment requests registered in the database 520, which recruitment requests are permitted to be disclosed to the applicant based on the disclosure permission list 521, and provides the applicant device 300 with the recruitment requests that are permitted to be disclosed to the applicant.

[0482] According to the third modification, there is no need to provide a server for centrally managing the system within the matching system.

[0483] <Modification 4> Modification 4 will be described using Fig. 53. Fig. 53 is a diagram showing an example (Modification 4) in which Kerberos authentication is applied to matching system 1A. As shown in Fig. 53, Kerberos authentication may be applied to authentication between companies in matching system 1A. Kerberos authentication is one of the network authentication methods applied between a server and a client.

[0484] Here, Modification 4 will be described using companies A and C as examples of multiple companies. As shown in FIG. 53 , authentication system 510A is installed in company A, and authentication system 510C is installed in company C. Authentication system 110 is a KDC (Key Distribution Center). Authentication system 110 is operated, for example, by an authentication authority. Authentication system 110 is configured by a server installed in the authentication authority. Authentication systems 510A and 510C are configured, for example, by user device 500 (see FIG. 52 ).

[0485] The authentication system 110 has a function of issuing a Ticket Granting Ticket (TGT). The authentication system 110 includes an Authentication Server (AS) and a Ticket Granting Server (TGS). The AS issues a Ticket Granting Ticket (TGT). The TGT is a ticket required to obtain a service ticket. The TGS issues a service ticket. By obtaining the service ticket, company A becomes able to send data to company C.

[0486] Here, an example will be described in which company A performs Kerberos authentication and then transmits a recruitment request to company C. Therefore, in this case, company A is the recruiter, and company C is the applicant. First, authentication system 510A requests authentication procedure from authentication system 110 (step Sk101). For example, authentication system 510A transmits information required for authentication, such as an ID and password for login, to the AS of authentication system 110. Authentication system 510A may use a public authentication key method for the authentication procedure.

[0487] The AS of the authentication system 110 performs authentication based on the information received from the authentication system 510A, and then transmits the TGT to the authentication system 510A (step Sk102). The authentication system 510A performs permission authentication for the case and obtains permission to issue a service ticket (step Sk103).

[0488] Next, the authentication system 510A requests a service ticket for company C from the TGS of the authentication system 110 (step Sk104). At this time, the authentication system 510A presents the TGT issued by the AS to the TGS. The TGS checks the TGT and then transmits the service ticket for company C to the authentication system 510A (step Sk105).

[0489] Next, authentication system 510A transmits the service ticket to authentication system 510C of company C to obtain transmission permission from company C (step Sk106). Authentication system 510C obtains the service ticket. Authentication system 510C transmits data transmission permission to authentication system 510A (step Sk107).

[0490] Thereafter, the authentication system 510A transmits to the authentication system 510C, from among the job listings registered in the job listing database 524, those for which disclosure to company C is permitted by the disclosure permission list 521. This allows company A to allow applicants from company C to view its job listings. Note that instead of each company storing its own disclosure permission list 521, the authentication system 110 may store the disclosure permission list 521 for all companies. In this case, the authentication system 110 has a function of determining the viewing authority for job listings.

[0491] When Kerberos authentication is applied to the matching system 1, company A can use the acquired TGT to simplify the authentication procedure when sending a job to a company other than company C. For example, when company A wants to send a job to company D, the authentication system 510A of company A presents the acquired TGT and requests a service ticket for company D from TGS. If there is no problem with the TGT, TGS issues a service ticket for company D to authentication system 510A.

[0492] By using the Kerberos authentication described above, a single sign-on technique can be implemented in the matching system 1. As a result, for example, when company A sends data such as job postings to other companies, authentication does not need to be performed for each company. Note that companies A and C are shown here as an example of multiple companies. However, the Kerberos authentication described above may also be applied as an authentication method between three or more multiple companies.

[0493] This embodiment has the following configuration: (a-1) An evaluation system for evaluating contractors who have applied for work, comprising a first evaluator device operated by one or more evaluators belonging to a first group, and a computing device that communicates with the first evaluator device and can access a database, wherein the first evaluator device accepts input of an evaluation of the contractor and transmits the accepted evaluation to the computing device, the computing device registers first evaluation information based on the evaluation received from the first evaluator device in the database for each contractor, and when the computing device receives a viewing request in a first communication established by identification information that can identify the person as belonging to the first group, it transmits the first evaluation information to the sender that sent the viewing request in the first communication.

[0494] (a-2) The system further includes a second evaluator device operated by one or more evaluators belonging to a second group different from the first group, wherein the second evaluator device accepts input of an evaluation of a contractor and transmits the accepted evaluation to a computing device, and the computing device registers second evaluation information based on the evaluation received from the second evaluator device in a database for each contractor, and when the computing device receives a viewing request in a second communication established by identification information that can identify the person as belonging to the second group, it transmits the second evaluation information to the sender that sent the viewing request in the second communication.

[0495] (a-3) A first group is composed of a first company, and a second group is composed of a second company different from the first company.

[0496] (a-4) The first group is made up of a first division of a first company, and the second group is made up of a second division of the first company.

[0497] (a-5) When the computing device receives evaluations of a specified contractor from multiple evaluators belonging to the first group, it calculates the average value of the evaluations of the specified contractor by the multiple evaluators, and transmits the average value as first evaluation information of the specified contractor to the sender that sent the viewing request in the first communication.

[0498] (a-6) The first group includes one or more evaluators belonging to the first divided group and one or more evaluators belonging to a second divided group different from the first divided group, and the computing device calculates a first average value that is an average value of the evaluations for the specified contractor based on the evaluations for the specified contractor received from the plurality of evaluators belonging to the first divided group, and the computing device calculates a second average value that is an average value of the evaluations for the specified contractor based on the evaluations for the specified contractor received from the plurality of evaluators belonging to the second divided group, and the computing device calculates a second average value that is an average value of the evaluations for the specified contractor received from the plurality of evaluators belonging to the first group. based on the above, calculates a third average value which is the average value of the evaluation for the specified contractor, and when the computing device receives a viewing request in a third communication established by identification information which can identify the person as belonging to the first divided group, transmits the first average value and the third average value to the sender that sent the viewing request in the third communication as the first evaluation information for the specified contractor, and when the computing device receives a viewing request in a fourth communication established by identification information which can identify the person as belonging to the second divided group, transmits the second average value and the third average value to the sender that sent the viewing request in the fourth communication as the first evaluation information for the specified contractor.

[0499] (a-7) A list of contractors is registered in the database, and when the first evaluator device receives an operation to search the list, it sends a search request to the computing device, and when the computing device receives the search request, it sends the search results, excluding from the list contractors whose evaluation level specified by the first evaluation information does not meet the standard, to the sender that sent the viewing request in the first communication.

[0500] (a-8) The database has multiple pieces of business information registered together with disclosure information indicating the scope of disclosure to applicants, and the evaluation system further includes an applicant device operated by an applicant belonging to the second group, and the computing device determines, based on the disclosure information, which pieces of business information from the multiple pieces of business information registered in the database are permitted to be disclosed to applicants belonging to the second group, and provides the applicant device with the business information that is permitted to be disclosed to applicants belonging to the second group.

[0501] (a-9) An evaluator device operated by one or more evaluators belonging to a first group, comprising an interface that accepts operations to input evaluations of contractors who have applied for work, a reception unit that accepts viewing requests, a display, and a processor that transmits the evaluations accepted by the interface and the viewing requests accepted by the reception unit to a computing device that can access the database, and when a viewing request is received, the processor displays the evaluations by one or more evaluators belonging to the first group on the display.

[0502] (a-10) A method for evaluating a contractor who has applied for a job, the method comprising the steps of: communicating with a first evaluator device operated by one or more evaluators belonging to a first group; receiving an evaluation of the contractor from the first evaluator device; registering first evaluation information based on the evaluation received from the first evaluator device in a database; and, when a viewing request is received in a first communication established by identification information that can identify the applicant as belonging to the first group, transmitting the first evaluation information to the sender that sent the viewing request in the first communication.

[0503] (b-1) An evaluation system for evaluating recruiters who are recruiting applicants for a job, comprising: a first evaluator device operated by one or more evaluators belonging to a first group; and a computing device that communicates with the first evaluator device and can access a database; the first evaluator device accepts input of an evaluation of the recruiter and transmits the accepted evaluation to the computing device; the computing device registers first evaluation information based on the evaluation received from the first evaluator device in the database for each recruiter; and when the computing device receives a viewing request in a first communication established by identification information that can identify the recruit as belonging to the first group, it transmits the first evaluation information to the sender that sent the viewing request in the first communication.

[0504] (b-2) Further provided is a second evaluator device operated by one or more evaluators belonging to a second group different from the first group, wherein the second evaluator device accepts input of an evaluation of the recruiter and transmits the received evaluation to a computing device, and the computing device registers second evaluation information based on the evaluation received from the second evaluator device in a database for each recruiter, and when the computing device receives a viewing request in a second communication established by identification information that can identify the person as belonging to the second group, it transmits the second evaluation information to the sender that sent the viewing request in the second communication.

[0505] (b-3) A first group is formed by a first company, and a second group is formed by a second company different from the first company.

[0506] (b-4) The first group is made up of a first division of a first company, and the second group is made up of a second division of the first company.

[0507] (b-5) When the computing device receives evaluations of a specified recruiter from multiple evaluators belonging to the first group, it calculates the average value of the evaluations of the specified recruiter by the multiple evaluators, and transmits the average value as first evaluation information of the specified recruiter to the sender that sent the viewing request in the first communication.

[0508] (b-6) The first group includes one or more evaluators belonging to the first divided group and one or more evaluators belonging to a second divided group different from the first divided group, and the computing device calculates a first average value, which is the average value of the evaluations for the specified recruiter, based on the evaluations for the specified recruiter received from the multiple evaluators belonging to the first divided group, and the computing device calculates a second average value, which is the average value of the evaluations for the specified recruiter, based on the evaluations for the specified recruiter received from the multiple evaluators belonging to the second divided group, and the computing device calculates a Based on this, the computing device calculates a third average value, which is the average value of the evaluations for the specified recruiter, and when the computing device receives a viewing request in a third communication established by identification information that can identify the person as belonging to the first divided group, it transmits the first average value and the third average value to the sender that sent the viewing request in the third communication as first evaluation information for the specified recruiter, and when the computing device receives a viewing request in a fourth communication established by identification information that can identify the person as belonging to the second divided group, it transmits the second average value and the third average value to the sender that sent the viewing request in the fourth communication as first evaluation information for the specified recruiter.

[0509] (b-7) A list of recruiters is registered in the database, and when the first evaluator device receives an operation to search the list, it sends a search request to the computing device, and when the computing device receives the search request, it sends the search results to the sender that sent the viewing request in the first communication, excluding from the list recruiters whose evaluation level specified by the first evaluation information does not meet the standard.

[0510] (b-8) The database has multiple pieces of business information registered together with disclosure information indicating the scope of disclosure to applicants, and the evaluation system further includes an applicant device operated by an applicant belonging to the second group, and the computing device determines, based on the disclosure information, which pieces of business information from the multiple pieces of business information registered in the database are permitted to be disclosed to applicants belonging to the second group, and provides the business information that is permitted to be disclosed to applicants belonging to the second group to the applicant device.

[0511] (b-9) An evaluator device operated by one or more evaluators belonging to a first group, comprising an interface that accepts operations to input evaluations of recruiters who are recruiting applicants for a job, a reception unit that accepts viewing requests, a display, and a processor that transmits the evaluations accepted by the interface and the viewing requests accepted by the reception unit to a computing device that can access the database, and when a viewing request is received, the processor displays the evaluations by one or more evaluators belonging to the first group on the display.

[0512] (b-10) A method for evaluating a recruiter who is recruiting applicants for a job, the method comprising the steps of: communicating with a first evaluator device operated by one or more evaluators belonging to a first group; receiving an evaluation of the recruiter from the first evaluator device; registering first evaluation information based on the evaluation received from the first evaluator device in a database; and, when a viewing request is received in a first communication established by identification information that can identify the person as belonging to the first group, transmitting the first evaluation information to the sender that sent the viewing request in the first communication.

[0513] (c-1) A matching system that matches applicants with recruiters seeking contractors for a job, the matching system comprising: a first applicant device operated by a first applicant; and a computing device that communicates with the first applicant device and can access a database, the computing device registers in the database business information for which contractors are sought and disclosure information indicating the scope of disclosure of the business information, the computing device determines, based on the disclosure information, business information that is permitted to be disclosed to the first applicant from the business information registered in the database, the business information including detailed information regarding the content of the job, and the computing device displays on the first applicant device the business information that is permitted to be disclosed to the first applicant and terms included in the detailed information.

[0514] (c-2) The terms included in the detailed information are in-house terms that are common in the group to which the recruiter belongs.

[0515] (c-3) The computing device registers the in-house terms and their meanings in the database.

[0516] (c-4) The computing device registers the in-house terms in a database according to the group to which the recruiter belongs.

[0517] (c-5) When the computing device detects an operation by the first applicant on an in-house term on the first applicant device, the computing device transmits information capable of identifying the meaning of the in-house term registered in the database to the first applicant device.

[0518] (c-6) The computing device searches for in-house terms included in the detailed information, and registers the business information in the database with the detected in-house terms associated with their meanings.

[0519] (c-7) A computing device included in a matching system that matches applicants with recruiters who are seeking contractors for a business, the computing device having a communication interface that communicates with a first applicant device operated by a first applicant, and a processor that accesses a database, wherein the processor registers in the database business information for which contractors are sought and disclosure information indicating the scope of disclosure of the business information, and the processor determines, based on the disclosure information, which business information from among the business information registered in the database is permitted to be disclosed to the first applicant, the business information includes detailed information regarding the content of the business, and the processor displays on the first applicant device the business information that is permitted to be disclosed to the first applicant and the meanings of terms included in the detailed information.

[0520] (c-8) A method for matching applicants with a recruiter seeking contractors for a job, the method comprising the steps of: communicating with a first applicant device operated by the first applicant; registering in a database business information for which contractors are sought and disclosure information indicating the scope of disclosure of the business information; and determining, from the business information registered in the database, business information that is permitted to be disclosed to the first applicant based on the disclosure information, wherein the business information includes detailed information regarding the content of the job; and the method further comprises the step of displaying on the first applicant device the business information that is permitted to be disclosed to the first applicant and the meanings of terms included in the detailed information.

[0521] (d-1) In the matching system, the recruiter device transmits business information for recruiting contractors and disclosure information indicating the scope of disclosure of the business information to the computing device, the computing device registers the business information together with the disclosure information in a database, the computing device determines, based on the disclosure information, which business information registered in the database is permitted to be disclosed to the first applicant, and provides the business information permitted to be disclosed to the first applicant to the first applicant device.

[0522] (d-2) The matching system further includes a second applicant device operated by a second applicant different from the first applicant, and the computing device determines, based on the disclosure information, business information that is permitted to be disclosed to the second applicant from among the business information registered in the database, and provides the business information that is permitted to be disclosed to the second applicant to the second applicant device.

[0523] (d-3) In the matching system, the matching system further includes a third applicant device operated by a third applicant different from the first applicant and the second applicant, and multiple disclosure levels are set for the disclosure information, and the computing device determines whether to allow disclosure for each of the first to third applicants depending on the disclosure level.

[0524] (d-4) In a matching system, a first applicant belongs to a first group, and a second applicant belongs to a second group different from the first group, and the multiple disclosure levels include a first level and a second level, the first level corresponding to allowing disclosure of business information to the first applicant and prohibiting disclosure of business information to applicants who do not belong to the first group, and the second level corresponding to allowing disclosure of business information to applicants who belong to either the first group or a community group that has formed a community relationship with the first group, and prohibiting disclosure of business information to applicants who do not belong to either the first group or the community group.

[0525] (d-5) In a matching system, a first applicant belongs to a first group, and a second applicant belongs to a second group different from the first group, and the multiple disclosure levels include a first level, a second level, and a third level, the first level corresponding to allowing disclosure of business information to the first applicant and prohibiting disclosure of business information to applicants who do not belong to the first group, the second level corresponding to allowing disclosure of business information to applicants who belong to either the first group or a community group that has formed a community relationship with the first group, and the third level corresponding to allowing disclosure of business information to applicants who belong to a community different from the first group and a second-level community group that has formed a community relationship with the first group, and prohibiting disclosure of business information to applicants who do not belong to either the first group or a community group.

[0526] (d-6) In the matching system, the plurality of disclosure levels includes a disclosure level corresponding to allowing disclosure of business information to applicants regardless of the group to which the applicant belongs.

[0527] (d-7) In the matching system, attribute data that can identify community groups is registered in the database, and the computing device identifies applicants who are permitted to disclose their business information based on the disclosure information and the attribute data.

[0528] (d-8) In the matching system, the recruiter device accepts an operation to input a target group to which disclosure of business information is prohibited, and transmits information that can identify the accepted target group to a computing device, and the computing device prohibits disclosure of business information to applicants belonging to the target group even if the disclosure level is a level that allows disclosure of business information to the target group.

[0529] (d-9) In the matching system, a first applicant belongs to a first company, and a second applicant belongs to a second company different from the first company.

[0530] (d-10) In the matching system, a computing device receives a request from a recruiter device to search for information on multiple registrants registered in a database, and provides the recruiter device with search results based on the received request. The recruiter device receives an operation from the recruiter to select from the search results a recommended applicant who is recommended to apply as an applicant, and transmits identification information of the selected recommended applicant to the computing device. The computing device then transmits information encouraging the applicant to apply to the applicant device of the selected recommended applicant.

[0531] (d-11) In the matching system, a computing device registers multiple pieces of profile information for each of multiple registrants in a database, and the computing device accepts input from each of the multiple registrants to set the range of the multiple pieces of profile information to be made public as search results.

[0532] (d-12) In the matching system, the recruiter device transmits recruitment type information to the computing device that can identify whether the job for which contractors are being recruited is a group job that can be accepted when multiple applicants apply jointly, or a job that can be accepted for an application by a single applicant, and the computing device registers the recruitment type information in the database in association with the job information.

[0533] (d-13) In the matching system, the computing device registers an application group consisting of multiple applicants in a database, and the computing device can accept applications from the application group regarding business information that is permitted to be disclosed to all applicants belonging to the application group.

[0534] [Aspects] Aspects of the present disclosure are listed below.

[0535] (Section 1) The matching system described in Section 1 is a matching system that provides project information that matches each of a plurality of groups including companies, and comprises a plurality of user devices and a computing device that communicates with each of the plurality of user devices and can access a database, the plurality of user devices including a first user device operated by a user belonging to a first group, and the database registers group information that can identify each of the plurality of groups, a plurality of project information, and prohibition information that can identify project information that prohibits associating the plurality of project information with a user belonging to the first group, the computing device associates one or more of the plurality of project information with a user belonging to the first group and delivers the one or more project information to the first user device based on the association, and the computing device associates the project information with a user belonging to the first group, excluding the project information identified by the prohibition information.

[0536] (Section 2) The matching system described in Section 2 is the matching system described in Section 1, wherein the multiple user devices include a second user device operated by a case owner belonging to a group different from the first group, and the second user device transmits case information of the case owner to a computing device, and the computing device registers the case information received from the second user device in a database.

[0537] (Clause 3) The matching system described in clause 3 is the matching system described in clause 1 or 2, in which the group information includes information for identifying either the company or an organization within the company.

[0538] (4) The matching system described in paragraph 4 is the matching system described in any one of paragraphs 1 to 3, wherein the prohibition information includes information indicating the competitive relationship between each of the multiple groups.

[0539] (Section 5) The matching system described in Section 5 is a matching system described in any one of Sections 1 to 4, wherein the database includes user attribute information and user behavior history information, and the computing device uses the attribute information and behavior history information to associate one or more of the multiple case information with users belonging to the first group.

[0540] (Section 6) The matching system described in Section 6 is the matching system described in Section 5, in which the computing device inputs attribute information and behavioral history information into a trained predictive model to match one or more of the multiple case information with users belonging to a first group, the behavioral history information includes information regarding the user's behavior in response to the case information, and the predictive model is trained by machine learning based on the attribute information and behavioral history information.

[0541] (Item 7) The matching system described in item 7 is a matching system described in any one of items 1 to 6, wherein the first user device has a display that displays case information.

[0542] (Clause 8) The matching system described in paragraph 8 is a matching system described in any one of paragraphs 1 to 7, which has a function of matching recruiters who are recruiting contractors for a job with applicants, and the multiple user devices include a recruiter device operated by the recruiter and a first applicant device operated by a first applicant, and the recruiter device transmits job information for recruiting contractors and disclosure information indicating the scope of disclosure of the job information to a computing device, the computing device registers the job information together with the disclosure information in a database, and the computing device determines, based on the disclosure information, which job information registered in the database is permitted to be disclosed to the first applicant, and provides the job information that is permitted to be disclosed to the first applicant to the first applicant device.

[0543] (Clause 9) The computing device described in clause 9 is a computing device included in a matching system that provides project information matching each of a plurality of groups including companies, and is equipped with a communication interface that communicates with a plurality of user devices including a first user device operated by a user belonging to a first group, and a processor that accesses a database, in which group information that can identify each of the plurality of groups, a plurality of project information, and prohibition information that can identify project information that prohibits associating the plurality of project information with a user belonging to the first group are registered, the processor associates one or more of the plurality of project information with a user belonging to the first group and delivers the one or more project information to the first user device, and the processor excludes the project information identified by the prohibition information and associates the project information with the user belonging to the first group.

[0544] (Clause 10) The method described in clause 10 is a method for providing project information that matches each of a plurality of groups including companies, and includes the steps of communicating with a plurality of user devices including a first user device operated by a user belonging to a first group, accessing a database in which group information capable of identifying each of the plurality of groups, a plurality of project information, and prohibition information capable of identifying project information that prohibits associating the plurality of project information with a user belonging to the first group is registered, associating one or more of the plurality of project information with a user belonging to the first group and delivering the one or more project information to the first user device, and excluding the project information identified by the prohibition information and associating the project information with a user belonging to the first group.

[0545] The embodiments disclosed herein should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is defined by the claims, not by the description of the above embodiments, and is intended to include all modifications within the meaning and scope of the claims.

[0546] 1 Matching system, 50 Internet, 100 Sharing server, 101 Processor, 102 Memory, 103 Storage, 104 Communication interface, 120 Database (DB), 121 Company database (Company DB), 122, 122A Member database (Member DB), 123 Community database (Community DB), 124, 124A Recruitment job database (Recruitment job DB), 125 Side job database (Side job DB), 126 Evaluation input database (Evaluation input DB), 126A Recruiter evaluation section, 126B Applicant evaluation section, 127 Evaluation summary database (Evaluation summary DB), 127A Recruiter evaluation summary section, 127B Applicant evaluation summary section, 128 Member group database (Member group DB), 129 Profile database (Profile DB), 131 Behavioral history database (Behavioral history DB), 132 Job introduction database (Job introduction DB), 133 Priority database (priority DB), 1271, 1272 data group, 140 community registration unit, 141 company registration unit, 142 member registration unit, 143 member search unit, 144 case registration unit, 145 case extraction unit, 146 application unit, 147 approval unit, 148 notification unit, 149 performance reception unit, 150 performance output unit, 151 evaluation reception unit, 152 evaluation output unit, 161 counter offer request unit, 162 counter offer approval request unit, 163 counter offer request acceptance notification unit, 200, 200A, 200B, 200C recruiter device, 201 processor, 202 memory, 203 communication interface, 204 input / output interface, 205 display, 206 operation unit, 206A keyboard, 206B mouse, 207, 250, 350 Screen, 300, 300A, 300B, 300C Applicant device, 301 Processor, 302 Memory, 303 Communication interface, 304 Input / output interface, 305 Display, 306 Operation unit, 306A Keyboard, 306B Mouse, 307A to 307C Tabs, 401, 402 Table, 500 User device, 1291 Project non-disclosure list.

Claims

1. A matching system that provides case information that matches each of a plurality of groups including companies, comprising: a plurality of user devices; and a computing device that communicates with each of the plurality of user devices and can access a database, the plurality of user devices including a first user device operated by a user belonging to a first group, the database registering group information capable of identifying each of the plurality of groups, a plurality of case information, and prohibition information capable of identifying case information that prohibits associating among the plurality of case information with a user belonging to the first group, the computing device associates one or more of the plurality of case information with a user belonging to the first group and delivers the one or more case information to the first user device, and the computing device associates the case information with the user belonging to the first group, excluding the case information identified by the prohibition information.

2. The matching system of claim 1, wherein the plurality of user devices includes a second user device operated by a case owner belonging to a group different from the first group, the second user device transmits the case information of the case owner to the computing device, and the computing device registers the case information received from the second user device in the database.

3. A matching system according to claim 1 or 2, wherein the group information includes information for identifying either a company or an organization within the company.

4. A matching system according to any one of claims 1 to 3, wherein the prohibition information includes information indicating a competitive relationship between each of the multiple groups.

5. A matching system as described in any one of claims 1 to 4, wherein the database includes attribute information of the user and behavioral history information of the user, and the computing device uses the attribute information and the behavioral history information to match one or more of the multiple case information with users belonging to the first group.

6. The matching system of claim 5, wherein the computing device inputs the attribute information and the behavioral history information into a trained predictive model to match one or more of the multiple case information with users belonging to the first group, the behavioral history information includes information regarding the user's behavior in response to the case information, and the predictive model is trained by machine learning based on the attribute information and the behavioral history information.

7. A matching system as described in any one of claims 1 to 6, wherein the first user device has a display for displaying the case information.

8. The matching system according to any one of claims 1 to 7, wherein the matching system has a function of matching recruiters who are seeking contractors for a job with applicants, and the multiple user devices include a recruiter device operated by the recruiter and a first applicant device operated by a first applicant, and the recruiter device transmits job information for which contractors are sought and disclosure information indicating the scope of disclosure of the job information to the computing device, and the computing device registers the job information together with the disclosure information in the database, and the computing device determines, based on the disclosure information, which job information registered in the database is permitted to be disclosed to the first applicant, and provides the job information permitted to be disclosed to the first applicant to the first applicant device.

9. A computing device included in a matching system that provides case information matching each of a plurality of groups including companies, the computing device comprising: a communications interface that communicates with a plurality of user devices including a first user device operated by a user belonging to a first group; and a processor that accesses a database, wherein the database registers group information capable of identifying each of the plurality of groups, a plurality of case information, and prohibition information capable of identifying case information that prohibits associating the plurality of case information with a user belonging to the first group, the processor associates one or more of the plurality of case information with a user belonging to the first group and delivers the one or more case information to the first user device, and the processor excludes the case information identified by the prohibition information and associates the case information with the user belonging to the first group.

10. A method for providing case information matching each of a plurality of groups including companies, comprising the steps of: communicating with a plurality of user devices including a first user device operated by a user belonging to a first group; accessing a database in which group information capable of identifying each of the plurality of groups, a plurality of case information, and prohibition information capable of identifying case information that prohibits associating the plurality of case information with a user belonging to the first group; associating one or more of the plurality of case information with a user belonging to the first group and delivering the one or more case information to the first user device; and excluding the case information identified by the prohibition information and associating the case information with the user belonging to the first group.

Images