Matching system, user device, compute device, and method

Abstract

A matching system (1) for matching business cases, the matching system comprising user devices (500) that are operated by users and a computing device (100) that is configured to access a database in which business cases are registered and to disclose business cases to users, wherein: the user devices (500) include first user devices operated by first users belonging to a first group, and second user devices operated by second users; the computing device (100) sets ranges of disclosure for business cases provided by the second users, on the basis of disclosure information indicating the ranges of disclosure of business cases; the first user devices transmit, to the computing device (100), restriction information that restricts business cases from being disclosed to the first group, on the basis of the first users' operations; and the computing device (100) restricts the business cases provided by the second users from being disclosed to the first group, in accordance with the restriction information, regardless of the ranges of disclosure set on the basis of the disclosure information.

Description

Technical Field

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

Background Art

[0002] Conventionally, crowdsourcing has been utilized in enterprises and the like. Generally, crowdsourcing refers to a process of soliciting contributions from an unspecified number of people and obtaining the required services, ideas, or content. In crowdsourcing, it is necessary to find personnel with the optimal capabilities for the required tasks.

[0003] Patent Document 1 describes a method of comparing whether information on the personnel required for a development project matches the information of the members of an enterprise, and extracting, as search results, members who match the required personnel from all organizations of the enterprise.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] The crowdsourcing described in Patent Document 1 is conducted within a single group, namely a company. However, to find more suitable personnel, it is desirable to further expand the scope of crowdsourcing. In this case, it is necessary to consider the interests of users when matching work projects. For example, the matching system should have a mechanism that allows the recruiter to control who the work project is disclosed to, so that the work project is not disclosed to competitors. However, simply having such a mechanism in the matching system may not be enough to prevent know-how from being leaked to competitors.

[0006] This disclosure was made to solve the above-mentioned problems, and its purpose is to allow for the restriction of the scope of disclosure of business opportunities, taking into account the interests of users when matching business opportunities. [Means for solving the problem]

[0007] The matching system relating to the first aspect of this disclosure is a matching system for matching business cases, comprising a user device operated by a user and a compute device configured to access a database in which business cases are registered and to disclose business cases to the user, wherein the user device includes a first user device operated by a first user belonging to a first group and a second user device operated by a second user, the compute device sets the scope of disclosure of business cases provided by the second user based on disclosure information indicating the scope of disclosure of business cases, the first user device transmits restriction information to the compute device that restricts the disclosure of business cases to the first group based on the operation of the first user, and the compute device restricts the disclosure of business cases provided by the second user to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the disclosure information.

[0008] The user device relating to the second aspect of this disclosure is a user device that communicates with a compute device that matches business cases, wherein the compute device is configured to access a database in which business cases are registered and to disclose business cases to the user, the compute device sets the scope of disclosure of business cases based on disclosure information indicating the scope of disclosure of business cases and restriction information, the user device comprises a receiving unit that receives user operations to input restriction information and a transmitting unit that transmits restriction information to the compute device when the user operation is received by the receiving unit, the restriction information is information that restricts the disclosure of business cases to the first group to which the first user belongs, regardless of the scope of disclosure based on the disclosure information.

[0009] The compute device relating to the third aspect of this disclosure is a compute device that communicates with a user device and matches business cases, and includes a setting unit that accesses a database in which business cases are registered and sets business cases to be disclosed to the first group to which the first user belongs based on disclosure information indicating the scope of disclosure of business cases, a receiving unit that receives restriction information from the user device that restricts the disclosure of business cases to the first group, and a restriction unit that, upon receiving restriction information, restricts the disclosure of business cases to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the disclosure information.

[0010] The method relating to the fourth aspect of this disclosure is a method for matching business cases, comprising the steps of: accessing a database in which business cases are registered and setting business cases to be disclosed to the first group to which the first user belongs, based on disclosure information indicating the scope of disclosure of business cases; receiving restriction information from the user device that restricts the disclosure of business cases to the first group; and, upon receiving the restriction information, restricting the disclosure of business cases to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the disclosure information. [Effects of the Invention]

[0011] According to this disclosure, the scope of disclosure of business opportunities can be limited to take into consideration the conflicts of interest between users when matching business opportunities. [Brief explanation of the drawing]

[0012] [Figure 1] This is a block diagram outlining the matching system. [Figure 2] This block diagram shows the configuration of the sharing server, recruiter equipment, and applicant equipment. [Figure 3] This figure shows an example of a corporate database. [Figure 4] This is a diagram showing an example of a member database. [Figure 5] This figure shows an example of a community database. [Figure 6] This figure shows an example of a job posting database. [Figure 7] This figure shows an example of a side job database. [Figure 8] This figure shows an example of an evaluation input database. [Figure 9] This figure shows an example of an evaluation summary database. [Figure 10] This diagram illustrates the functions of the sharing server, the recruiter device, and the applicant device. [Figure 11] This diagram illustrates the functions of the sharing server, the recruiter device, and the applicant device. [Figure 12] This diagram illustrates the functions of the sharing server, the recruiter device, and the applicant device. [Figure 13] This is a diagram to further explain the functions of the applicant's device. [Figure 14] This diagram illustrates the procedure for registering job postings in the job posting database. [Figure 15] This diagram illustrates the procedure for searching for job postings within a database. [Figure 16] This diagram illustrates the procedure for registering planned and completed side jobs in a database. [Figure 17] This is a diagram for explaining the procedure of registering evaluations of applicants in a database. [Figure 18] This is a diagram for explaining the procedure of registering evaluations of recruiters in a database. [Figure 19] This is a diagram for explaining the procedure of displaying evaluations of applicants and search results of members on a display. [Figure 20] This is a diagram for explaining the procedure of displaying evaluations of recruiters and search results of members on a display. [Figure 21] This is a diagram for explaining the viewable range of an evaluation summary database. [Figure 22] This is a diagram showing an example where a disclosure range is set according to a disclosure level. [Figure 23] This is a diagram showing the screen displayed on an applicant device when a manager (the applicant's supervisor) checks the part-time job status of a subordinate. [Figure 24] This is a diagram showing the screen displayed on an applicant device when a manager changes the setting of viewing restrictions. [Figure 25] This is a diagram showing a timing chart related to the setting of restriction information. [Figure 26] This is a diagram showing the details of the content of a recruitment case included in a recruitment case database. [Figure 27] This is a diagram showing an example of a profile database. [Figure 28] This is a diagram showing an example of an in-house terminology database. [Figure 29] This is a flowchart showing the processing procedure related to the indexing function of a matching system. [Figure 30] This is a flowchart showing the processing procedure of an in-house terminology registration section. [Figure 31] This is a flowchart showing the processing procedure of a case registration section. [Figure 32] This is a flowchart showing the processing procedure for displaying the meaning of in-house terminology on a screen according to an applicant's operation. [Figure 33]As an example of variation 1, this is a flowchart showing the processing of restriction information performed by the sharing server. [Figure 34] This diagram illustrates the functions of the sharing server, recruiter device, and applicant device related to Modification Example 2. [Figure 35] This figure shows an example of a member database related to the second variation. [Figure 36] This flowchart shows the processing procedure for the reverse offer member search process related to Modification 2. [Figure 37] This block diagram shows the configuration of the sharing server, recruiter device, and applicant device related to Modification Example 3. [Figure 38] This figure shows an example of a member group database related to the 3rd modification. [Figure 39] This figure shows an example of a recruitment database related to Modification Example 3. [Figure 40] This diagram illustrates the functions of the sharing server, recruiter device, and applicant device related to Modification Example 3. [Figure 41] This diagram illustrates the procedure for registering a recruitment request related to Modification Example 3 in the recruitment request database. [Figure 42] This diagram shows the configuration of the matching system related to the 4th variation. [Figure 43] This figure shows an example of applying Kerberos authentication to a matching system (modification 5). [Modes for carrying out the invention]

[0013] The embodiments of this disclosure will be described in detail below with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals, and their descriptions will not be repeated.

[0014] [Background for proposing Matching System 1] Figure 1 is a block diagram illustrating the overview of the matching system 1 related to this embodiment. First, the background for proposing the matching system 1 in this embodiment will be explained.

[0015] Matching System 1 can be used, for example, in crowdsourcing between companies. Crowdsourcing is generally the process of soliciting contributions from a large number of people to obtain the services, ideas, or content that are needed.

[0016] Many companies are promoting side jobs to make effective use of their human resources. By using crowdsourcing between companies, they can leverage the skills of their employees.

[0017] However, applying general crowdsourcing methods directly between companies may lead to the following problems:

[0018] [Potential for confidential information to be leaked] Conventional crowdsourcing methods often fail to consider the relationship between the client company and the contractor company, thus creating both corporate and individual risks when adopting crowdsourcing. For example, there is a risk that confidential information could be leaked to a rival company through an employee's side job. Traditional crowdsourcing methods also make it impossible for managers to verify that employees are not taking on projects for competitors as a side job.

[0019] [Potential for overwork] If companies allow employees to have side jobs, there is a risk that employees' working hours will become excessively long. To mitigate the risk of overwork, companies may consider setting limits on overtime hours, including both main job and side job hours. However, as long as employees are free to accept side jobs, it will be difficult for companies to manage their side job hours. As a result, employees may end up in a state of overwork.

[0020] [The possibility that the results of your side job may not be fairly evaluated] Traditionally, crowdsourcing systems have existed that require clients to evaluate contractors. When appropriate evaluations made by clients are shared within the crowdsourcing system, those recruiting contractors can use these evaluations as a reference to select highly capable individuals from among many applicants.

[0021] However, a client from one company might, out of consideration for other companies' contractors being evaluated, enter a higher rating into the system than the actual value should be. Alternatively, a client might avoid giving a low rating to another company's contractor to avoid damaging inter-company relations. Furthermore, a client might not see any benefit in conducting an evaluation and enter a rating far removed from the actual value. Considering these possibilities, the reliability of the evaluations provided by the system may be reduced. In this case, even if evaluations of contractors are shared, the client cannot use those evaluations as reference data when selecting a contractor.

[0022] [There is a possibility that accurate information about the recruiters may not be available.] In the crowdsourcing system described above, applicants will likely choose a job that suits them, taking into account the job description, compensation, and other factors. However, some recruiters may frequently request additional work or changes to the job description that fall outside the scope of the contract. Applicants would naturally want to avoid such recruiters when applying for jobs. Conversely, there are also recruiters who complete the work without any problems. Applicants would naturally prefer to apply for jobs offered by such recruiters. Therefore, it is desirable to widely share not only evaluations of applicants (contractors) but also evaluations of recruiters (clients) within the crowdsourcing system.

[0023] If appropriate evaluations of recruiters are shared through a crowdsourcing system, those who are considering applying for work can use these evaluations as a reference and select a suitable job from among many available opportunities, taking into account the recruiter's past transaction history and other factors.

[0024] However, building an evaluation system that allows for the evaluation of recruiters can present similar problems to those that allow for the evaluation of contractors. Specifically, a contractor (applicant) from one company might enter a higher rating into the system than their actual worth, out of consideration for the client (recruiter) of another company being evaluated. Also, a contractor (applicant) from one company might avoid giving a low rating to another company's client (recruiter) to avoid damaging inter-company relations. Furthermore, a contractor (applicant) might not see any benefit in providing an evaluation and enter a rating far removed from their actual worth. Considering these possibilities, the reliability of the evaluations provided by the system may decrease. In this case, even if evaluations of recruiters are shared, applicants will not be able to use those evaluations as reference data when selecting a recruiter.

[0025] [The unique characteristics of having companies as the main actors in the matching process] Generally, matching personnel and tasks across companies requires a close relationship, such as trust, between the companies involved. Therefore, matching personnel and tasks between companies that do not have capital ties is extremely difficult. Furthermore, large companies, such as publicly listed companies, tend to compete with other companies due to their diversified businesses, leading to cannibalization. This creates a unique situation where they cannot match personnel and tasks with a large number of companies.

[0026] [Internal company jargon can hinder communication] In some companies, internal jargon specific to that company may be widely used. While this internal jargon may be understood by people within the company where it is used, there is a risk that it will not be understood by people outside that company. Alternatively, while internal jargon may be understood as having a specific meaning among people within the company where it is used, there is a risk that people outside that company may understand it as having a different meaning.

[0027] The job description may contain internal company terminology. If the recruiter's company and the applicant's company are different, the applicant may not correctly understand the meaning of the internal terminology used by the recruiter in the job description. The applicant may apply for the job without correctly understanding the meaning of the internal terminology used by the recruiter in the job description. As a result, there is a risk of work-related problems.

[0028] Internal company jargon may be used during meetings between recruiters and applicants. If the recruiter and the applicant belong to different companies, the applicant may not correctly understand the meaning of the internal jargon used by the recruiter. Similarly, the recruiter may not correctly understand the meaning of the internal jargon used by the applicant.

[0029] Recruiters and Applicants If one party uses unfamiliar company jargon, the other party can understand its meaning by asking the speaker for clarification. However, if the recruiter and applicant have different understandings of a particular company term, the meeting will proceed without correcting this misunderstanding. This could result in business-related problems.

[0030] Terms similar to company jargon can be prevalent not only in corporations but also in non-profit organizations, where they may have their own unique meanings. Regardless of whether an organization is for-profit or non-profit, it may be divided into multiple units such as departments or divisions, and each unit may have its own specific terminology. Alternatively, such terminology may be prevalent in communities formed by the gathering of multiple organizations such as companies. Therefore, when the recruiter and the applicant belong to different organizations, units, or communities, differences in the understanding of terminology may lead to the aforementioned work-related problems.

[0031] In this embodiment, "in-house terminology" refers not only to "internal terminology" used in for-profit organizations such as corporations and their units, but also to "terms similar to internal terminology" used in non-profit organizations, communities, and their units. Below, this embodiment will be explained using "internal terminology" for corporations as an example of "in-house terminology."

[0032] In this embodiment, with the aim of solving at least one of the various problems that conventional crowdsourcing faces, we propose the matching system 1 described in detail below.

[0033] [Overall structure] Referring to Figure 1, the general configuration of the matching system 1 will be explained. The matching system 1 comprises a sharing server 100, recruiter devices 200A, 200B, 200C..., and applicant devices 300A, 300B, 300C....

[0034] The sharing server 100 provides a matching service to numerous companies, facilitating the matching of business orders and acceptances between companies. Figure 1 shows companies A, B, C, etc., as examples of companies that use the matching service. Companies A, B, C, etc. are registered as corporate members of Matching System 1. Employees of Companies A, B, C, etc., who use Matching System 1 are also individually registered as members of Matching System 1.

[0035] The work offered through Matching System 1 is, for example, temporary work that is expected to be completed within a predetermined period. Therefore, those who accept work offered through Matching System 1 will engage in their primary work in their specific department within the company, and the work offered through Matching System 1 as a secondary job. In Matching System 1, for example, an applicant from Company A can also accept work from Company A. Therefore, in Matching System 1, it is permissible for an applicant belonging to a different department Y of Company A to accept work from department X of Company A.

[0036] Hereinafter, in Matching System 1, the work for which contractors are being recruited may be referred to as "recruited work," "recruitment project," or "project," the person providing the recruitment project may be referred to as the "recruiter," and the person applying to receive the recruitment project may be referred to as the "applicant." Applying to recruited work may be referred to as "applying to recruited work" or "applying to recruitment project (project)."

[0037] An applicant who wins a project is considered a "contractor," and the person who commissions the project to the contractor is considered a "client." However, in the following, "applicants" may be included in the term "contractor," and "clients" may be included in the term "commissioner."

[0038] The sharing server 100 has a database 120 built on it that is necessary for the matching service. Database 120 includes various databases that contain information necessary for providing the matching service. For example, database 120 contains information on members and recruitment activities. The sharing server 100 is managed and operated by a company separate from the companies that use the matching service. Any company that uses the matching service may manage and operate the sharing server 100.

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

[0040] 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 device 300". Figure 1 shows two applicants for each company, but the number of applicants is not limited to this. There may be many more applicants for each company, or a company may have only one applicant. Sharing server 100 may accept applicants who are not affiliated with a company, such as freelancers.

[0041] In this embodiment, the managers of companies A, B, C, etc., will assume the role of recruiters. Therefore, in the following, the managers of each company may be referred to as "recruiters." Recruiters can also act as applicants for jobs advertised by other recruiters. In that case, recruiter device 200 will function as applicant device 300. In this embodiment, when a company manager acts as a recruiter, the device that the manager uses to utilize the matching service will be referred to as recruiter device 200.

[0042] Company A may have one administrator or multiple administrators. When assigning administrators to Company A, each administrator may be given a recruiter device 200, or a single recruiter device 200 may be shared by multiple people. The same applies to Companies B, C, etc.

[0043] The sharing server 100 and the recruiter device 200 are configured to communicate via the Internet 50, which is an example of a communication network. The sharing server 100 and the recruiter device 300 are configured to communicate via the Internet 50.

[0044] The sharing server 100 requires sign-in, including the input of a member ID and password, when accepting access from the recruiter device 200. Similarly, the sharing server 100 requires sign-in, including the 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 provided during sign-in.

[0045] The recruiter device 200 accepts various operations from the recruiter. For example, the recruiter device 200 accepts operations such as inputting job postings (requested tasks), inputting evaluations of contractors who have completed the tasks, and searching for members of the matching service.

[0046] The recruiter device 200 communicates with the sharing server 100 in response to each operation performed on the recruiter device 200. The sharing server 100 registers the recruitment request (requested work) in the database 120 in response to an operation to input the recruitment request (requested work), registers the 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.

[0047] The applicant device 300 accepts various operations from the applicant. For example, the applicant device 300 accepts operations such as searching for job postings, applying for job postings, and entering work experience.

[0048] The applicant device 300 communicates with the sharing server 100 in response to each operation performed 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 notification of acceptance or rejection to the applicant device 300 in response to an operation to apply for a job posting, and registers the work performance in the database 120 in response to an operation to input work performance.

[0049] As described above, Matching System 1 includes an evaluation system for evaluating applicants (contractors) for work and a recruitment system for soliciting contractors for work.

[0050] A recruiter belonging to a certain department of Company A can use Matching System 1 to hire an applicant belonging to another department of Company A as a contractor for a recruitment project. A recruiter belonging to Company A can use Matching System 1 to hire an applicant belonging to Company B as a contractor for a recruitment project.

[0051] In the following, members of Matching System 1 may be referred to as "users." Furthermore, the recruiter device 200 and applicant device 300 operated by members may be collectively referred to as "user device 500." Users utilizing Matching System 1 access the sharing server 100 as either recruiters or applicants using the "user device 500."

[0052] Various information is displayed on the user device 500. For example, when a user accesses the sharing server 100 as an applicant, a list of available job postings is displayed on the user device 500. The user can select a job posting they wish to apply for from this list. In particular, Figure 1 shows the "List of Open Job Postings" screen 551, which is displayed when a user signs up for the sharing server 100 in administrator mode. By viewing the "List of Open Job Postings," the user can learn about all job postings disclosed to the company to which they belong.

[0053] The "List of Open Jobs" includes an area where users can set restrictions on viewing job postings. This area is not displayed if a user signs up for Sharing Server 100 in general mode, not administrator mode. Users with administrator privileges can select job postings from the many available that they do not want employees of their company to see, and set viewing restrictions for those postings. Job postings with viewing restrictions set will no longer be disclosed to the company to which the user with administrator privileges belongs.

[0054] Thus, in this embodiment, only users with administrator privileges can configure settings related to restrictions on viewing business cases. However, the system may be configured so that only those authorized by a user with administrator privileges can configure settings related to restrictions on viewing business cases. Alternatively, the system may be configured so that any user can configure settings related to restrictions on viewing business cases.

[0055] When a user accesses the sharing server 100 as a recruiter, the user can also display the applicant's profile on the user device 500. The user can use the user device 500 to look up the applicant's work history, etc. Alternatively, the user device 500 may display the job requirements. The user (applicant) looks at screen 552 on the user device 500 to check the details of the job. The user (recruiter) looks at screen 552 to look up the applicant's work history, etc. Alternatively, screen 552 may display reports on ongoing work, instructions to change part of the request, instructions to add to the request, etc. The user checks the contents displayed on screen 552 and uses the user device 500 to perform necessary actions such as replying to the other party with the required information.

[0056] The information displayed on screen 552, such as job requirements, work history, work reports, and instructions, may contain internal 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 internal company terminology.

[0057] Therefore, the matching system 1 registers the internal terminology and its meanings for each company in the database 21. The matching system 1 generates an index of internal terminology from the job postings and other documents used by the user and links it to the internal terminology registered in the database 21. In this way, the matching system 1 has an indexing function.

[0058] If the text displayed on screen 552 contains company terminology, the user device 500 displays the company terminology in a different manner from other terms. This allows the user to understand that it is company terminology. Furthermore, in response to user actions (for example, clicking on the company terminology), the user device 500 displays the intended meaning of the company term on screen 552.

[0059] For example, in screen 552 shown in Figure 1, "DX" is displayed as an example of internal company terminology. "DX" is underlined to indicate that it is internal company terminology. The user clicks on "DX." Then, a window explaining the meaning of the term "DX" appears on screen 552. DX is an abbreviation for Digital Transformation, and generally means transformation using digital technology. However, some companies may use "DX" as internal company terminology to mean creating some kind of new value, regardless of whether digital technology is used or not. In such cases, the window on screen 552 explains the meaning corresponding to that internal company term. This allows the user to correctly understand the meaning of "DX" as intended by the other party.

[0060] Figure 2 is a block diagram showing the configuration of the sharing server 100, the recruiter device 200, and the applicant device 300.

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

[0062] Memory 102 includes RAM (Random Access Memory), ROM (Read Only Memory), flash memory, or any other suitable memory system. Memory 102 stores programs necessary for the arithmetic processing of processor 101, as well as temporary data calculated during the arithmetic processing.

[0063] Storage 103 consists of hard disk drives and solid-state drives, etc. Storage 103 stores database 120. Database 120 contains multiple types of databases. These 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, and an evaluation input database (evaluation input DB This includes )126 and the evaluation summary database (evaluation summary DB)127.

[0064] Some of these multiple types of databases may be stored in storage separate from the sharing server 100. For example, some of the multiple types of databases shown in Figure 2 may be stored on a cloud service separate from the sharing server 100. In this case, the sharing server 100 can access the necessary databases by communicating with the cloud via the internet 50.

[0065] The processor 101 connects to the Internet 50 via the communication interface 104, following a program stored in memory 102. The processor 101 communicates with the recruiter device 200 and the applicant device 300 after connecting to the Internet 50. The processor 101 accesses the database 120 and performs processes such as extracting necessary data, registering new data in the database 120, and updating data registered in the database 120.

[0066] [Configuration of recruiter device 200] The recruiter device 200 comprises a processor 201, memory 202, communication interface 203, input / output interface 204, display 205, and operation unit 206. The operation unit 206 consists of a mouse and keyboard, etc.

[0067] Memory 202 includes RAM (Random Access Memory), ROM (Read Only Memory), flash memory, or any other suitable memory system. Memory 202 stores programs necessary for the arithmetic operations of processor 201, as well as temporary data calculated during those operations.

[0068] The processor 201 connects to the internet 50 via the communication interface 203, following a program stored in 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 performs processes such as sending job postings, displaying information of applicant members on the display 205, assigning work to selected contractors from among the applicants, and sending the contractor evaluations entered by the recruiter to the sharing server 100.

[0069] Information entered through the operation of the control unit 206 is notified to the processor 201 via the input / output interface 204.

[0070] [Configuration of applicant device 300] The applicant device 300 comprises a processor 301, memory 302, communication interface 303, input / output interface 304, display 305, and operation unit 306. The operation unit 306 consists of a mouse and keyboard, etc.

[0071] Memory 302 includes RAM (Random Access Memory), ROM (Read Only Memory), flash memory, or any other suitable memory system. Memory 302 stores programs necessary for the arithmetic processing of the processor 301, as well as temporary data calculated during the arithmetic processing.

[0072] The processor 301 connects to the Internet 50 via the communication interface 303 according to the 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 performs processes such as applying for job postings, displaying notifications of acceptance or rejection of the applied job on the display 305, and sending the results of the received work to the sharing server 100.

[0073] Information entered through the operation of the control unit 306 is notified to the processor 301 via the input / output interface 304.

[0074] [Overview of Database 120] The following is an overview of database 120. Company database 121 contains information on companies participating in matching system 1. Member database 122 contains information on members who use matching system 1. Many members are employees of companies participating in matching system 1.

[0075] Members registered in the member database 122 can use the matching system 1 to work as recruiters (clients) or applicants (contractors). Members may include employees of companies registered in the company database 121, as well as individuals (freelancers) who are not affiliated with any company.

[0076] The community database 123 stores information for identifying companies belonging to a community. Communities are formed by agreement between companies. Therefore, multiple communities can be formed depending on how the companies reach an agreement. The number of companies belonging to a single community can also be set in various ways. Companies that have community relationships form a relationship of trust to the extent determined by how the agreement was reached when the community was formed. The community database 123 registers information for identifying companies belonging to each community.

[0077] The job posting database 124 contains registered projects (job postings) for which contractors are being sought. Employees of each company can, while performing their primary duties in their respective departments within the company, become members of Matching System 1 and accept projects from other departments within their own company or from other companies that are registered in the job posting database 124. In this case, members accept projects from other departments within their own company or from other companies as a side job.

[0078] The side job database 125 registers data on each member's side job status. This data includes information such as past side job activities and planned side job activities.

[0079] The evaluation input database 126 contains information on evaluations of applicants (contractors) for work. The client (ordering party) can use the matching system 1 to evaluate the work performance of applicants (contractors) after they have completed the work. The evaluations given by individual evaluators are registered in the evaluation input database 126.

[0080] Evaluation summaries are registered in the evaluation summary database 127. Evaluation summaries are registered for each member in the evaluation summary database 127. Recruiters can view evaluation summaries. Recruiters can view the evaluation summaries of members who have applied for the recruitment project and select members they deem suitable as contractors.

[0081] [Company Database 121] Figure 3 shows an example of the company database 121. The company database 121 registers company IDs, company names, company addresses, and maximum working hours for side jobs for each company. The maximum working hours for side jobs is the maximum number of hours that an employee is permitted to work as a side job in addition to their main job. The maximum working hours for side jobs are determined by each company. For example, the maximum working hours for side jobs can be calculated as "standard overtime hours - overtime hours in the main job excluding the side job." "Standard overtime hours" vary from company to company. Note that while Figure 3 shows the maximum working hours for side jobs on a monthly basis, it may also be shown as a weekly limit. Each company may also define its own unit for the maximum working hours for side jobs.

[0082] In this embodiment, members are permitted to apply for and accept work offered by various companies and departments, provided that they do not exceed the maximum number of hours for side jobs set by the company to which they belong.

[0083] [Member Database 122] Figure 4 shows an example of the member database 122. The member database 122 contains various information about members. This information includes a member ID to identify the member, the ID of the company to which the member belongs, the member's name, the member's authority, the department to which the member belongs, and the hours during which the member is permitted to work part-time.

[0084] Member privileges include administrator and applicant. Members with administrator privileges are authorized to use Matching System 1 as both recruiters and applicants. Members with applicant privileges are authorized to use Matching System 1 as applicants, but not as recruiters. Department heads within a company are granted administrator privileges to manage the side-job status of their subordinates. Administrators with administrator privileges are authorized to approve applications from their subordinates who are applicants. Therefore, administrators function as approvers.

[0085] The available time for side jobs is the remaining time that can be spent on side jobs. This time is calculated as "maximum available time for side jobs - total available time for side jobs". If an individual is engaged in multiple side jobs, the total available time for side jobs includes the time already spent on those jobs. In addition to the time already spent on side jobs, the total available time for side jobs includes the estimated time for side jobs. The estimated time for side jobs is calculated based on the estimated man-hours registered in the job posting database 124. Figure 4 shows the available time for side jobs on a monthly basis. Applicants using the matching system 1 to search for job postings are only offered jobs that can be handled within the man-hours of their available time for side jobs.

[0086] [Community Database 123] Figure 5 shows an example of the community database 123. The community database 123 registers information about communities formed between companies. The community information includes a community ID to identify 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. Companies belonging to a community can change the companies that belong to that community by agreement with other companies.

[0087] [Job Posting Database 124] Figure 6 shows an example of the recruitment database 124. The recruitment database 124 contains information about recruitment opportunities. The recruitment information includes a project ID to identify the recruitment opportunity, the ID of the company to which the recruiter who registered the recruitment opportunity belongs, a list of non-disclosed company IDs, the recruiter's member ID, disclosure level, restricted information, project title, estimated man-hours, estimated duration, and project details.

[0088] For example, the list of non-disclosing company IDs registers the IDs of companies whose job postings are not to be disclosed. The disclosure level can be set to one of three levels: "Company only," "Within the community," or "All." If the disclosure level is set to "All," applicants from outside the community are also included in the disclosure. Restriction information is the information regarding viewing restrictions shown in Figure 1. Restriction information is set for each applicant company for each job posting.

[0089] On the right side of the recruitment database 124 in Figure 6, the IDs of companies that can view the recruitment postings are shown. For example, for the recruitment posting corresponding to posting ID=001, the disclosure level is set to "Our Company". In this case, only members belonging to the company that registered the recruitment posting (company ID=00A) can view the recruitment posting corresponding to posting ID=001.

[0090] Hereafter, using the project ID, the recruitment projects corresponding to each project ID may be referred to as project 001, project 002, project 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. Furthermore, using a part of the company ID, the companies corresponding to each company ID may be referred to as company A, company B, company C, etc.

[0091] In case 002, the disclosure level is set to "within the community." According to the community database 123 shown in Figure 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 Figure 6, only members belonging to company A, company B, or company C can view case 002.

[0092] However, if the administrator of company B has set viewing restrictions for project 002, the recruitment project database 124 will contain restriction information to prevent members of company B from viewing project 002. In this case, only members belonging to either company A or company C will be able to view project 002.

[0093] Case 003 has the same registered companies and disclosure level as Case 002. However, in Case 003, "00B" is registered in the list of non-disclosing company IDs. 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.

[0094] For job postings where the disclosure level is set to "All," all members can view the job posting. Job posting 005, shown in Figure 6, falls into this category. If one or more company IDs are registered in the non-disclosure company ID list for job posting 005, members belonging to those companies will not be granted permission to view job posting 005.

[0095] The estimated workload and estimated time are used by applicants and the matching system 1 to estimate the time required to process the job posting.

[0096] Regarding the setting of disclosure levels, various variations can be considered. For example, users could be allowed to control who sees the disclosure of business information by selecting specific items. More specifically, a checkbox could be provided on the screen for registering job postings to select the companies to which the business information will be disclosed. Alternatively, users could be allowed to control related information and functions by selecting one of a predefined option. For example, the screen for registering job postings could display a list that allows users to select the scope of disclosure of business information from "within the company," "within the community," and "all users."

[0097] The user device 500 may provide the user with a settings screen for setting various disclosure levels. For example, the settings screen may display checkboxes for the user to select the target market for disclosure by industry, such as "pharmaceuticals," "chemicals," "electrical equipment," "railways and buses," and "food." Furthermore, by displaying the names of companies corresponding to each industry on the settings screen, the user may be able to select the target market for disclosure by "industry" and by "company."

[0098] For example, let's assume that companies A, B, C, and D represent the "pharmaceuticals" sector, companies E, F, G, and H represent the "chemicals" sector, and companies I, J, K, and L represent the "electrical equipment" sector.

[0099] In this case, the settings screen will indicate that the "Pharmaceuticals" industry includes "Company A" through "Company D," and will display checkboxes corresponding to "Pharmaceuticals," "Company A," "Company B," "Company C," and "Company D." Furthermore, the settings screen will indicate that the "Chemicals" industry includes "Company E" through "Company H," and will display checkboxes corresponding to "Chemicals," "Company E," "Company F," "Company G," and "Company H." Furthermore, the settings screen will indicate that the "Electrical Equipment" industry includes "Company I" through "Company L," and will display checkboxes corresponding to "Electrical Equipment," "Company I," "Company J," "Company K," and "Company L."

[0100] 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 will be excluded from the list of companies whose projects are publicly available. Furthermore, suppose the user has checked the checkboxes corresponding to companies A through C in the "Pharmaceuticals" category and companies E through H in the "Chemicals" category, but does not check the checkbox corresponding to company D in the "Pharmaceuticals" category. In this case, companies A through C in the "Pharmaceuticals" category and companies E through H in the "Chemicals" category will be included in the list of companies whose projects are publicly available, but company D in the "Pharmaceuticals" category will be excluded from the list of companies whose projects are publicly available.

[0101] [Side Job Database 125] Figure 7 shows an example of the side job database 125. The side job database 125 registers information indicating the status of members' side jobs for each side job project. The information indicating the status of side jobs includes the ID of the member engaged in the side job, the project ID, the month (duration of engagement in the side job), the planned hours of the side job, the actual hours of the side job, the estimated hours of the side job, and the progress rate.

[0102] The planned time for side work is the estimated time required for a member to process a project they have already accepted. Members who have accepted side work enter their planned time for side work each month using their applicant device 300. The entered planned time for side work is reflected in the side work database 125. For example, the estimated man-hours for project 001 are set to 5 hours / person / month in the recruitment project database 124. This means that the workload is 5 hours per person per month. Typically, members enter their planned time for side work based on the estimated man-hours for the recruitment project.

[0103] The recorded hours for side jobs represent the actual time spent by a member on a project they have already accepted. In other words, the recorded hours for side jobs represent the time a member has already worked. Until a project is completed, members enter the hours spent on that project into their applicant device 300 at any time they choose to do so. The cumulative value of the hours entered into the applicant device 300 is registered in the side job database 125 as the recorded hours for side jobs each month.

[0104] The estimated side work time is the time expected to be required for the tasks of the project in question. In other words, the estimated side work time is the time expected to be part of the member's future working hours. The sharing server 100 automatically sets the estimated side work time, taking into account the planned side work time and the actual side work time. Members may be allowed to input their estimated side work time at any time using their applicant device 300 until the tasks of the project in question are completed. Alternatively, members may be allowed to modify the estimated side work time once it has been automatically set. It is desirable that the estimated side work time is less than or equal to the planned side work time. However, depending on the circumstances of the project, the estimated side work time may be longer than the planned side work time. Members working on a project may be allowed to update their estimated side work time at any time until the tasks of the project are completed.

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

[0106] For example, when a member initially accepts a project, the progress rate is 0%, the actual time spent on side work is 0 hours, and the planned time and estimated time for side work match. As the member progresses with the project and enters the actual time spent on side work and the progress rate, the estimated time for side work changes accordingly.

[0107] The side job database 125 shown in Figure 7 contains data on member P2's side jobs 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 projects 001 and 002 between October 2021 and December 2021.

[0108] For the October data of project 001, the side job database 125 records planned side job hours = 5, actual side job hours = 10, and estimated side job hours = 10. From this, it can be seen that member P2 engaged in project 001 in October, exceeding the planned side job hours.

[0109] For the November data for project 002, the side job database 125 records planned side job hours = 10, actual side job hours = 4, and estimated side job hours = 8. From this, it can be seen that member P2 worked on project 002 in November without exceeding the set estimated side job hours. Since the progress rate is 50, it can be seen that member P2 completed half of the entire work for project 002 in November.

[0110] For the December data of project 001, the side job database 125 has registered planned side job hours = 5 and estimated side job hours = 5, but the actual side job hours are not registered. Similarly, for the December data of project 002, the actual side job hours are not registered. This means that we are waiting for member P2 to input the actual side job hours.

[0111] The sharing server 100 uses the estimated and actual side job hours from the side job database 125 to calculate the available capacity for additional side jobs that a member can take on. If a member is engaged in multiple side jobs, the sharing server 100 calculates the "total estimated side job hours," which is the sum of the estimated side job hours corresponding to those multiple side jobs, and the "total actual side job hours," which is the sum of the actual side job hours corresponding to those multiple side jobs. The sharing server 100 calculates the available side job capacity by calculating "maximum side job hours - (total estimated side job hours + total actual side job hours)." Here, if "total estimated side job hours + total actual side job hours" is defined as "total side job hours," then the available side job capacity, i.e., "available side job hours," will be calculated as "maximum side job hours - total side job hours." For example, in the side job database 125 shown in Figure 7, the total estimated side job hours for member P2 in December are 15 hours (5 hours + 10 hours). Furthermore, member P2's total hours spent on side jobs in December were zero. In this case, if the "maximum hours for side jobs" set by the company to which member P2 belongs is 30 hours, then member P2's available time for side jobs (time available for side jobs) can be calculated as 15 hours (30 hours - 15 hours).

[0112] Here, we will explain an example of a more specific procedure for calculating estimated side work hours. For example, "estimated side work hours" may be calculated based on the formula "(work progress rate / progress rate) × planned side work hours - actual side work hours". Here, "work progress rate" is calculated by "actual side work hours / planned side work hours". As explained earlier, the "progress rate" is the rate entered into the side work database 125 at the discretion of the person engaged in the side work.

[0113] For example, if the planned time for a side job is 10 hours and the actual time spent on the side job is 2 hours, the progress rate is calculated as 20%. Now, let's assume the progress rate is 40%. In this case, the estimated time for the side job is calculated as "(20% / 40%) × 10 hours - 2 hours" = 3 hours. In other words, according to this calculation, the estimated time for the side job in question is 3 hours.

[0114] [Evaluation Input Database 126] Figure 8 shows an example of the evaluation input database 126. The evaluation input database 126 registers evaluation information for the person being evaluated. The evaluation information includes the person being evaluated, the member ID of the person being evaluated, the member ID of the evaluator, and the evaluation result.

[0115] The evaluation input database 126 includes a recruiter evaluation unit 126A and an applicant evaluation unit 126B. The recruiter evaluation unit 126A stores evaluation information for recruiters (clients). The applicant evaluation unit 126B stores evaluation information for applicants (contractors).

[0116] In the Recruiter Evaluation Unit 126A, the person being evaluated is the recruiter (client), and the evaluator is the applicant who applied for the job being recruited by the person being evaluated and was awarded the job. The Recruiter Evaluation Unit 126A registers the evaluation of the person being evaluated by each evaluator. Figure 8 shows an example where members P1 and P2, who are the people being evaluated, are being evaluated by evaluator members. In particular, Figure 8 shows an example where member P1 is being evaluated by evaluator members P5, P7, P11, and P12. The evaluation result (evaluation value) is expressed as a numerical value with a maximum value of 10 and a minimum value of 0.

[0117] In the Applicant Evaluation Unit 126B, the person being evaluated (the person being evaluated) is the applicant (contractor) for the project, and the evaluator is the project's recruiter (client). The Applicant Evaluation Unit 126B registers the evaluation of the person being evaluated, separately for each evaluator. Figure 8 shows an example where member P7, who is the person being evaluated, is evaluated by members P1, P2, and P3, who are the evaluators. Although the example of the evaluation results in the Applicant Evaluation Unit 126B is omitted in Figure 8, various evaluation results are registered there, similar to the Recruiter Evaluation Unit 126A.

[0118] When an applicant (contractor) completes a project commissioned by a recruiter (client), they use the applicant device 300 to evaluate the recruiter (the person being evaluated) as an evaluator. The evaluator's evaluation results are registered in the evaluation input database 126. If an applicant receives another project from a recruiter from whom they have previously received work, the applicant evaluates that recruiter again. In this case, the average of the previous and subsequent evaluation results is registered in the evaluation input database 126.

[0119] When an applicant (contractor) completes the work assigned to them by the recruiter (client), the recruiter 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. If a recruiter assigns another task to an applicant who has previously been assigned a task, the recruiter evaluates that applicant again. In this case, the average of the previous and subsequent evaluation results is registered in the evaluation input database 126.

[0120] Therefore, the evaluation results registered in the evaluation input database 126 reflect the average value of each evaluator's evaluation of the person being evaluated. Alternatively, a weighted average value and a standard score calculated according to the number of evaluations may be used instead of the average value. The evaluation input database 126 may also further register evaluation results for each case ID.

[0121] [Evaluation Summary Database 127] Figure 9 shows an example of the evaluation summary database 127. The evaluation summary database 127 registers departmental evaluation information for those being evaluated. Organizational evaluation information includes the person being evaluated, 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 the evaluation summary.

[0122] The evaluation summary database 127 includes the recruiter evaluation summary section 127A and the applicant evaluation summary section 127B. In the recruiter evaluation summary section 127A, the subject of evaluation (the person being evaluated) is the recruiter (the client). In the applicant evaluation summary section 127B, the subject of evaluation (the person being evaluated) is the applicant (the contractor). The evaluation summary database 127 registers evaluation summaries for the subjects of evaluation by department.

[0123] The evaluation summary is calculated based on the aggregated results of the evaluation input database 126. The departmental categories include individual departments within a company, such as the "Systems Department" and the "Planning Department," as well as "Overall," which represents the entire company. The evaluation summary is calculated separately for each of these "departments."

[0124] Figure 9 shows an example where member P1 is the person being evaluated, as the recruiter evaluation summary section 127A. The company ID of the person being evaluated is "00A". Therefore, member P1 belongs to company A. In Figure 9, data group 1271 represents company B's evaluation of member P1 acting as a recruiter, and data group 1272 represents company C's evaluation of member P1 acting as a recruiter.

[0125] Referring to data set 1271, it can be seen that the evaluation of Company B is categorized into an overall company evaluation, 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.

[0126] For example, the evaluation summary for the entire company B registers the average of the evaluation results of company B members who evaluated member P1 acting as a recruiter. In Figure 9, this value is shown as "4.75". The evaluation summary for the systems department registers the average of the evaluation results of company B members belonging to the systems department who evaluated member P1 acting as a recruiter. In Figure 9, this value is shown as "4.0". The evaluation summary for the planning department registers the average of the evaluation results of company B members belonging to the planning department who evaluated member P1 acting as a recruiter. In Figure 9, this value is shown as "5.0".

[0127] Similar to data group 1271, data group 1272 also classifies the evaluation of company C into an overall company evaluation and evaluations 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.

[0128] The above explains the recruiter evaluation summary section 127A in detail. Next, we will explain the applicant evaluation summary section 127B. Figure 9 shows an example in the applicant evaluation summary section 127B where member P7 is the person being evaluated. The company ID of the person being evaluated is "00C". Therefore, member P7 belongs to company C. The applicant evaluation summary section 127B registers the evaluations of member P7, who is acting as an applicant, by department.

[0129] The applicant evaluation summary section 127B has the same structure as the recruiter evaluation summary section 127A, except that the subject of evaluation is the "applicant" and not 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.

[0130] The sharing server 100 uses the evaluation input database 126 to identify each member's evaluation result and the member database 122 to identify each member's affiliation. Based on these identification results, the sharing server 100 updates the data in the evaluation summary database 127.

[0131] Although Figure 9 only shows members P1 and P7 as those being evaluated, members P2-P6, P8, and P9 are also similarly registered in the evaluation summary database 127 as those being evaluated. The evaluation summary database 127 may also include data where the same member is evaluated as both a recruiter and an applicant. For example, in addition to the recruiter evaluation summary for member P1, the evaluation summary database 127 shown in Figure 9 may also contain an applicant evaluation summary for member P1.

[0132] [Functions of the sharing server, recruiter device, and applicant device] Figures 10 to 12 are diagrams illustrating the functions of the sharing server, recruiter device, and applicant device.

[0133] As shown in Figure 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 the processor 101, memory 102, storage 103, and communication interface 104 provided by the sharing server 100.

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

[0135] Community information includes the community name and information about the companies belonging to the community. The community registration unit 140 registers the community in the community database 123 according to the system administrator's input (step S1). The community registration unit 140 also has a function to update the community information registered in the community database 123.

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

[0137] The company information includes information such as the company name, address, and maximum hours for side jobs. The company registration unit 141 registers the company in the company database 121 according to the system administrator's input (step S2). The company registration unit 141 also has a function to update the information of companies that have already been registered.

[0138] The Member Registration Unit 142 has the function of registering (signing up) new members who wish to join Matching System 1. The Member Registration Unit 142 issues a Member ID and password upon request from a person belonging to a company that is a member of Matching System 1. A person who wishes to become a member performs the signup process using a personal computer or the like (Step S3).

[0139] Specifically, those wishing to become members enter information such as their name, affiliated company, and department into a personal computer and send the entered information to the sharing server 100. The member registration unit 142 registers the entered 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 either a recruiter device 200 or an applicant device 300.

[0140] Figure 10 shows two applicant devices 300. One device is intended to be operated by the manager of the applicant company. The other device is intended to be operated by someone other than the manager within the applicant company. The manager of the applicant company holds a management position such as department head and is the superior of the applicants who are their subordinates. In this embodiment, the manager of the applicant company plays the role of an approver who approves applications to job postings submitted by their subordinates.

[0141] The member search unit 143 has a function to search 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 the recruiter device 200 and the applicant device 300 with information on members registered in the member database 122.

[0142] When the recruiter device 200 receives a search operation from a recruiter, it executes a member search process (step S4A). This allows the recruiter to view, for example, applicant information. The recruiter can then consider the applicant information and select the person to award the contract to from among multiple applicants. Similarly, when the applicant device 300 receives a search operation from an administrator who is the supervisor of a certain applicant, it executes a member search process (step S4A).

[0143] Furthermore, when the applicant device 300 receives a search operation from an applicant, it executes a member search process (step S4B). This allows the applicant to view, for example, the recruiter's information. The applicant then considers the recruiter's information and selects from among multiple recruitment jobs to accept. stomach You can choose your tasks.

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

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

[0146] The recruitment case registration process (step S5) performed by the recruiter device 200, and the processing of the case registration unit 144 will be explained in detail later with reference to Figure 14.

[0147] As shown in Figure 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 the processor 101, memory 102, storage 103, and communication interface 104 provided by the sharing server 100.

[0148] The case extraction unit 145 has the function of extracting job postings that applicants can view. The application unit 146 has the function of submitting applications from applicants to the administrator (applicant's supervisor). The approval unit 147 has the function of sending the content of the application for the job posting to the recruiter, conditional on receiving approval of the application from the administrator (approver). The notification unit 148 has the function of receiving the result from the recruiter regarding whether or not to hire the applicant, and notifying the applicant and the administrator of the result.

[0149] The application unit 146, the approval unit 147, and the notification unit 148 use a workflow system to send notifications to administrators requesting approval, notify recruiters of applicants, and notify applicants of the application results.

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

[0151] When the case extraction unit 145 receives a search request, it extracts cases from the recruitment cases registered in the recruitment case database 124 that are permitted for viewing by applicants, and transmits the extracted cases to the applicant device 300. The case extraction unit 145 determines whether a case is permitted for viewing by applicants based on the first and second criteria. The first criterion is the scope of disclosure set for the recruitment case. The second criterion is the applicant's available time for side work. The scope of disclosure is determined by the disclosure information shown in Figure 14. The available time for side work is calculated as the available time for side work shown in Figure 15.

[0152] The case extraction unit 145 determines that cases that meet both the first and second criteria are cases that applicants are allowed to view. Therefore, the case extraction unit 145 selects from the recruitment cases registered in the recruitment case database 124 that meet the search request. send The system extracts cases for which disclosure to applicants is permitted. Furthermore, the case extraction unit 145 extracts cases from the recruitment cases registered in the recruitment case database 124 that meet the search request. send The system extracts projects that the applicant can handle within their available time for side work. The project extraction unit 145 sends projects that the applicant is allowed to view to the applicant device 300.

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

[0154] The applicant device 300 receives job postings from the job posting extraction unit 145. The applicant device 300 displays the received job postings on the display 305 (step S7).

[0155] The job posting search process (step S6), the job posting display process (step S7), and the process of the job posting extraction unit 145 will be explained in detail later using Figure 15.

[0156] The applicant selects a job posting to apply for from those displayed on the display 305 of the applicant device 300. The applicant device 300 then executes the application process in response to the applicant's operation (step S8). During the application process, the applicant device 300 transmits application information indicating the job to be applied for to the application unit 146 of the sharing server 100. This transmits the applicant's desire to accept the job from the applicant device 300 to the application unit 146.

[0157] Application section 146 is the applicant device 30 0 The application information received is sent to the applicant device 300 of the administrator (applicant's supervisor). The application unit 146 identifies the supervisor's member ID, who is the applicant's administrator, based on the relationship between the applicant's member ID and the supervisor's member ID, which is registered in the member database 122. The application unit 146 sends the subordinate's application information to the applicant device 300 corresponding to the identified supervisor's member ID. The administrator checks the work the subordinate has applied for on their own applicant device 300. The administrator performs an operation on the applicant device 300 to approve the application. The applicant device 300 accepts the approval operation and executes the application approval process (step S9). In the application approval process, the applicant device 300 sends the approval information to the approval unit 147 of the sharing server 100. As a result, approval information, which is an example of an approval notification, is sent from the administrator's (approver's) applicant device 300 to the approval unit 147.

[0158] The approval unit 147 accepts an applicant's application on the condition that it has received approval information from the applicant device 300. Thus, in this embodiment, an applicant's application is accepted on the condition that it is approved by the manager to which the applicant belongs. Therefore, the manager can check in advance the content of the recruitment work that their subordinate intends to apply for. As a result, it is possible to prevent confidential information from being leaked outside the company through an employee's side job.

[0159] Figure 11 shows the process when the administrator approves an application. If, for example, an operation to reject the application is received in step S9, rejection information is sent from the administrator's applicant device 300 to the approval unit 147. Upon receiving the rejection information, the approval unit 147 may notify the applicant's applicant device 300 of the rejection of the application.

[0160] The approval unit 147, upon receiving an applicant's application, transmits the application information to the recruiter device 200. The application information includes the applicant's information and the details of the job being applied for. The recruiter device 200 displays the application details on the display 205 (step S10). The recruiter reviews the applicant and the job being applied for based on the display 205 and decides whether or not to hire the applicant.

[0161] The recruiter inputs the result of their decision to accept or reject the candidate into the recruiter device 200. The recruiter device 200 accepts the input result (step S11). The recruiter device 200 transmits the accepted acceptance or rejection result to the notification unit 148 of the sharing server 100.

[0162] When the notification unit 148 receives the acceptance or rejection result from the recruiter device 200, it transmits the application result (acceptance or rejection result) to the applicant's applicant device 300 and the administrator's applicant device 300.

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

[0164] As shown in Figure 12, the sharing server 100 functionally includes a performance reception unit 149, a performance output unit 150, an evaluation reception unit 151, and an evaluation output unit 152. These various functions are realized by the processor 101, memory 102, storage 103, and communication interface 104 provided by the sharing server 100.

[0165] The performance reception unit 149 has the function of receiving the planned and actual hours of side work entered by the applicant in the applicant device 300. The performance output unit 150 has the function of outputting information including the applicant's planned and actual hours of side work to the recruiter device 200 or the administrator's applicant device 300.

[0166] The evaluation reception unit 151 has the function of receiving evaluations of applicants (contractors) entered by the recruiter in the recruiter device 200. The evaluation output unit 152 has the function of outputting information indicating the evaluation of applicants to the recruiter device 200.

[0167] When an applicant engages in a side job, they input their planned and actual hours of work into the applicant device 300. Typically, when an applicant accepts a new side job, they input their planned hours into the applicant device 300, and at any time while they are working on the side job, they input their actual hours of work into the applicant device 300. For example, if an applicant accepts a side job that is expected to last for several months, they input their actual hours of work into the applicant device 300 each month.

[0168] The applicant device 300 accepts input of the planned and actual hours of the side job (step S14). The applicant device 300 transmits the accepted planned and actual hours of the side job to the performance reception unit 149 of the sharing server 100.

[0169] The performance reception unit 149 registers the received planned and actual part-time work hours in the part-time work database 125. The processing of step S14 performed by the applicant device 300 and the processing of the performance reception unit 149 will be explained in detail later with reference to Figure 16.

[0170] The performance output unit 150 transmits the planned and actual hours of side work registered in the side work database 125 to the recruiter device 200 and the administrator's applicant device 300. The recruiter device 200 displays the received information, including the planned and actual hours of side work, on the display 205, and the administrator's applicant device 300 displays the received information, including the planned and actual hours of side work, on the display 305 (step S15). However, when comparing the information transmitted to the recruiter device 200 and the information transmitted to the administrator's applicant device 300, the cases to which the information is transmitted are different.

[0171] From the performance reception unit 149, data corresponding to the projects handled by the subordinate is transmitted to the administrator's applicant device 300 from among the many projects registered in the side job database 125. The administrator can check the subordinate's side job status by looking at the display 305. The screen displayed on the administrator's applicant device 300 when the administrator checks the subordinate's side job status will be explained later with reference to Figure 23.

[0172] From the performance reception unit 149 to the recruiter device 200, data corresponding to the projects that recruiters have posted among the many projects registered in the side job database 125 is transmitted. For example, consider the case in the side job database 125 shown in Figure 7, where, among several recruiters, the first recruiter has posted project 001 and the second recruiter has posted project 002.

[0173] In this case, various data corresponding to case 001 from the side job database 125 are transmitted from the performance reception unit 149 to the recruiter device 200 operated by the first recruiter. Various data corresponding to case 002 from the side job database 125 are transmitted from the performance reception unit 149 to the recruiter device 200 operated by the second recruiter.

[0174] The first and second recruiters can check the progress of their projects by viewing the planned and actual hours of side work displayed on the display 305 of the recruiter device 200.

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

[0176] The recruiter device 200 transmits the received evaluations to the evaluation reception unit 151 of the sharing server 100. The evaluation reception 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.

[0177] The processing of step S16A performed by the recruiter device 200 and the processing of the evaluation reception unit 151 will be explained in detail later with reference to Figure 17.

[0178] When the recruiter device 200 receives an operation from the recruiter to view the applicant's evaluation, it executes a viewing request process (step S17A). In the viewing request process, the recruiter device 200 sends the viewing request to the evaluation output unit 152 of the sharing server 100. In response to the viewing request, the evaluation output unit 152 sends 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).

[0179] The processing of steps S17A and S18A performed by the recruiter device 200 and the processing of the evaluation output unit 152 will be explained in detail later with reference to Figure 19.

[0180] Figure 13 is a diagram illustrating the functions of the applicant device 300. Here, Figure 13 is used to explain the input and output of evaluations of recruiters. The evaluation reception unit 151 further includes the function of receiving evaluations of recruiters entered by applicants in the applicant device 300. The evaluation output unit 152 further includes the function of outputting information indicating the evaluation of the recruiter to the applicant device 300. When an applicant completes the work they have been awarded, they input their evaluation of the recruiter into the applicant device 300. There are various points that applicants consider when evaluating recruiters.

[0181] For example, if an applicant can communicate smoothly with the recruiter and complete the work within a reasonable timeframe, the applicant will likely give the recruiter a high rating. Conversely, if there are many requests for additions, changes, and modifications to the work content, if too much time is spent outside the scope of the work, if instructions are given too late, or if instructions regarding modifications to the work content are given unilaterally without prior consultation, the applicant will likely give the recruiter a low rating.

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

[0183] The applicant device 300 transmits the received evaluation to the evaluation reception unit 151 of the sharing server 100. The evaluation reception 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.

[0184] The processing of step S16B performed by the applicant device 300 and the processing of the evaluation reception unit 151 will be explained in detail later with reference to Figure 18.

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

[0186] The processes of steps S17B and S18B performed by the applicant device 300, and the processes of the evaluation output unit 152 will be explained in detail later with reference to Figure 20.

[0187] [Details of the processing by the case registration unit 144 and the recruiter device 200] Figure 14 is a diagram illustrating the procedure for registering job postings in the job posting database 124. Using Figure 14, we will explain in more detail step S5 in Figure 10 and the function of the job posting registration unit 144.

[0188] A recruiter registering a job posting first signs in to the sharing server 100 using the recruiter device 200. This establishes a logical communication path between the recruiter device 200 and the sharing server 100, identified by the recruiter's member ID. Next, the recruiter uses the mouse and keyboard or other operating unit 206 to input the job posting's business information and disclosure information into the recruiter device 200.

[0189] Information entered by 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 operations for entering the content of the business and operations for entering disclosure information that specifies the target to which the business will be disclosed.

[0190] The job information for a job posting includes the job title, job description, estimated man-months, and estimated duration. Disclosure information includes the disclosure level. Depending on the recruiter's selection, disclosure information may include the ID of companies that are not being disclosed.

[0191] The recruiter device 200 receives the business information and disclosure information of the recruitment project and executes the process of registering the recruitment project (step S5). In the process of registering the recruitment project, the recruiter device 200 sends the business information and disclosure information of the recruitment project to the sharing server 100.

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

[0193] 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 applicant device 300. When the sharing server 100 receives any information from the recruiter device 200 or applicant device 300 in a communication established using this member ID, it identifies the member who sent that information using the member ID used for signing in.

[0194] Therefore, when the recruiter device 200 receives business information and disclosure information for the recruiting business, the case registration unit 144 uses the member ID used for signing in to identify the recruiter operating the recruiter device 200. The case registration unit 144 uses the identified member ID, member database 122, and company database 121 to identify the member who is the recruiter and the company to which the recruiter belongs.

[0195] Next, the project registration unit 144 executes the process of registering the recruitment project in the recruitment project database 124 (step S1442). Specifically, after generating a project ID, the project registration unit 144 registers the company information (company ID), the ID of companies to be kept confidential, the disclosure level, the project title, the estimated man-hours, the estimated period, and the project details in the recruitment project database 124, associating them with the generated project ID.

[0196] According to this embodiment, recruiters can freely control the scope of disclosure of their recruitment opportunities at the levels of "within their own company," "within the community," and "unrestricted." As a result, they can prevent recruitment opportunities from being disclosed to specific companies unintentionally.

[0197] According to this embodiment, it is possible to set companies that are not to be disclosed separately from the disclosure level. Therefore, recruiters can set the scope of disclosure by excluding some of the companies that have community relationships with the company to which they belong. As a result, it is possible to prevent business related to a specific company within the community from being disclosed to that specific company.

[0198] Instead of, or in addition to, the list of non-disclosable company IDs, a list of non-disclosable member IDs may be provided in the recruitment database 124 for registering member IDs whose disclosure of recruitment opportunities is prohibited. The recruiter device 200 may accept an operation to specify members whose disclosure of recruitment opportunities is prohibited and send the ID of that member to the sharing server 100. The sharing server 100 may refrain from providing recruitment opportunities corresponding to member IDs listed in the non-disclosable member ID list to members whose IDs are listed in that list. In this way, the recruiter device 200 may accept either companies or members as those whose disclosure of business is prohibited.

[0199] Figure 15 is a diagram illustrating the procedure for searching for job postings from the database 120. Using Figure 15, the processes of steps S6 and S7 in Figure 11, and the functions of the job posting extraction unit 145 will be explained in more detail.

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

[0201] When the case extraction unit 145 receives a search request, it extracts cases from the recruitment database 124 that are permitted for viewing by applicants. To this end, the case extraction unit 145 executes the processes in steps S1451 to S1454.

[0202] Steps S1451 and S1452 are processes that extract job postings that applicants are allowed to view, based on the disclosure scope set for each posting. In step S1451, the applicant's affiliated company and the community within that company are determined. In step S1452, the postings that can be disclosed are extracted.

[0203] Step S1453 is the process of extracting job postings that the applicant is allowed to view, based on their available capacity for side work. Step S1454 is the final process of extracting job postings that match the applicant.

[0204] [Process to extract cases based on the scope of disclosure] Step S1451 includes steps S1451A and S1451B.

[0205] In step S1451A, the applicant's affiliated company is identified based on the member ID used during sign-in, company database 121, and member database 122.

[0206] In step S1451B, the community of the applicant's company is identified based on the applicant's company ID and community database 123.

[0207] Step S1452 includes steps S1452A and S1452B. In step S1452A, based on the applicant's affiliated company's community and disclosure level, the job postings that can be disclosed are extracted from the job posting database 124.

[0208] In step S1452B, job postings extracted in step S1452A that include the applicant's company on the list of non-disclosed companies are excluded. Here, the job postings extracted by the process in step S1452B are referred to as Job Posting X.

[0209] [Process to extract projects based on available capacity for side jobs] Step S1453 includes steps S1453A, S1453B, and S1453C.

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

[0211] The total hours spent on side jobs are calculated using the formula "total estimated hours + total actual hours" based on the estimated and actual hours of side jobs registered in the side job database 125. In other words, total hours spent on side jobs include both the time already spent on side jobs and the estimated time not yet spent on side jobs.

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

[0213] In step S1453C, job postings that satisfy the condition "Time T2 ≤ Available time for side work T1" are extracted from the job posting database 124. Here, the job postings extracted by the process in step S1453C are referred to as job postings Y.

[0214] [Process to extract projects based on disclosure scope and available capacity for side jobs] The case selection unit 145 extracts case X based on the disclosure scope and case Y based on the available capacity for side work, and then extracts cases that overlap between case X and case Y as matching cases for applicants (step S1454).

[0215] [Process to provide extracted cases] Next, the case extraction unit 145 transmits information on matching cases to the applicant device 300 (step S1455). The applicant device 300 receives the matching cases. The applicant device 300 displays the received matching cases as recruitment cases on the display 305 (step S7).

[0216] This ensures that applicants receive job postings that are appropriate from two perspectives. Firstly, applicants are provided with job postings that do not exceed their maximum allowable hours for side work. This prevents applicants from becoming overworked. Secondly, job postings from recruiters are only provided 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.

[0217] [Process to register planned and actual hours worked on side jobs] Figure 16 is a diagram illustrating the procedure for registering planned and actual side job activities in the database 120. Using Figure 16, the functions of step S14 in Figure 12 and the actual activity reception unit 149 will be explained in more detail.

[0218] For example, when an applicant accepts a new side job, they input the planned hours for the side job into the applicant device 300, and at any time while working on the side job, they input the actual hours worked into the applicant device 300. The applicant device 300 accepts the input of the planned hours for the side job (step S14). The applicant device 300 transmits the accepted planned hours and actual hours worked to the performance reception unit 149 of the sharing server 100.

[0219] The performance reception unit 149 receives the applicant's planned and actual hours of work for their side job, and registers the received planned and actual hours of work for the applicant in the side job database 125 (step S1511). As a result, the side job database 125 registers the applicant's monthly planned and actual hours of work for their side job, categorized by project ID.

[0220] Typically, applicants enter their planned hours for side work, and then at the end of the month, they enter their actual hours worked. Therefore, the side work database 125 may contain cases where planned hours are registered, but actual hours are not. For example, when an applicant who has accepted a side job enters their planned hours, the data for that job will include the planned hours, but not the actual hours worked.

[0221] Next, the performance reception unit 149 automatically calculates the estimated side work hours for the current month (step S1512). The performance reception unit 149 calculates the estimated side work hours based on the planned side work hours and the actual side work hours. Specifically, the "estimated side work hours" are calculated based on the formula "(work progress rate / progress rate) × planned side work hours - actual side work hours," as explained earlier. Alternatively, the performance reception unit 149 may calculate the "estimated side work hours" using the formula "planned side work hours - actual side work hours." The performance reception unit 149 registers the calculated estimated side work hours in the side work database 125. As shown in the side work database 125 in Figure 7, the estimated side work hours are registered for each project ID.

[0222] [Process for registering evaluation results (evaluation of applicants)] Figure 17 is a diagram illustrating the procedure for registering applicant evaluations in the database 120. Using Figure 17, step S16A in Figure 12 and the functions of the evaluation reception unit 151 will be explained in more detail.

[0223] Upon completing the side job, the applicant delivers the work and reports its completion to the recruiter, who then inspects it. The recruiter then operates the recruiter device 200 to input an evaluation of the applicant. The recruiter device 200 accepts the input evaluation (step S16A). The recruiter device 200 transmits the received evaluation to the evaluation reception 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-10) of the applicant who is being evaluated.

[0224] When the evaluation reception unit 151 receives evaluation information for 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).

[0225] If the evaluation reception unit 151 already has evaluation results registered for the person being evaluated (applicant) in the evaluation input database 126, it calculates the average value of the evaluation results for the person being evaluated, including the evaluation value received this time. The evaluation reception unit 151 updates the evaluation results registered in the evaluation input database 126 with the calculated average value. As a result, the average value of the evaluation (evaluation result) for the person being evaluated (applicant) is registered in the evaluation input database 126 for each evaluator (recruiter). This updates the information in the applicant evaluation unit 126B in the evaluation input database 126.

[0226] Next, the evaluation reception unit 151 performs evaluation summary processing (step S1514A). In evaluation summary processing, the evaluation reception unit 151 calculates the average evaluation result for each person being evaluated (applicant) by company and department, and registers the calculation result in the evaluation summary database 127. As a result, the information in the applicant evaluation summary unit 127B is updated in the evaluation summary database 127.

[0227] For example, the evaluation reception unit 151 identifies the evaluator (recruiter) using the member ID that the recruiter device 200 used 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 reception 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 allows the sharing server 100, including the evaluation reception unit 151, to identify the affiliation (company and department) of a person who has accessed the sharing server 100."

[0228] The evaluation reception unit 151 accesses the evaluation summary database 127 and detects data rows containing the identified 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 reception unit 151 updates the applicant evaluation summary values ​​corresponding to the detected data rows.

[0229] [Process for registering evaluation results (evaluation of recruiters)] Figure 18 is a diagram illustrating the procedure for registering evaluations of recruiters in the database. Using Figure 18, step S16B in Figure 13 and the function of the evaluation reception unit 151 will be explained in more detail.

[0230] As described above, once the applicant completes the side job, they deliver the work and submit a completion report to the recruiter, and the recruiter inspects it. After that, the applicant 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 received evaluation to the evaluation reception 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).

[0231] When the evaluation reception unit 151 receives evaluation information for the person being evaluated (recruiter) from the applicant device 300, it reflects the evaluation of the person being evaluated in the evaluation input database 126 (step S1513B).

[0232] If the evaluation reception unit 151 has already registered evaluation results for the person being evaluated (recruiter) in the evaluation input database 126, it calculates the average value of the evaluation results for the person being evaluated, including the evaluation value received this time. The evaluation reception unit 151 updates the evaluation results registered in the evaluation input database 126 with the calculated average value. As a result, the average value of the evaluation (evaluation result) for the person being evaluated (recruiter) is registered in the evaluation input database 126 for each evaluator (applicant). This updates the information of the recruiter evaluation unit 126A in the evaluation input database 126.

[0233] Next, the evaluation reception unit 151 performs evaluation summary processing (step S1514B). In evaluation summary processing, the evaluation reception unit 151 calculates the average evaluation result for each 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.

[0234] For example, the evaluation reception unit 151 identifies the evaluator (applicant) using the member ID that the applicant device 300 used to sign in in order to execute step S16B. Based on the evaluation information received in step S1513B, the company database 121, and the member database 122, the evaluation reception 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 allows the sharing server 100, including the evaluation reception unit 151, to identify the affiliation (company and department) of a person who has accessed the sharing server 100."

[0235] The evaluation reception unit 151 accesses the evaluation summary database 127 and detects data rows containing the identified 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 reception unit 151 updates the recruiter evaluation summary values ​​corresponding to the detected data rows.

[0236] For example, in data set 1271 of Figure 9, the member ID of the person being evaluated is P1, the ID of the company to which the person being evaluated belongs is 00A, and the ID of the company to which the evaluator belongs is 00B. If a member belonging to the systems department of company B evaluates member P1, the evaluation is accepted in step S1513B.

[0237] In this case, in step S1514B, the recruiter evaluation summary corresponding to "Overall" and the recruiter evaluation summary corresponding to "Systems Department" of data group 1271 are updated with the evaluations received in step S1513B.

[0238] More specifically, the evaluation reception unit 151 uses the average value of the evaluations for the entire company B, including the evaluations received in step S1513B, as the recruiter evaluation summary corresponding to "Overall" in data group 1271. Similarly, the evaluation reception unit 151 uses the average value of the evaluations for the system department, including the evaluations received in step S1513B, as the recruiter evaluation summary corresponding to "System Department" in data group 1271.

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

[0240] [Process to output a summary of applicant evaluations] First, we will explain the processes in steps S17A, S18A, S1521A, and S1522A, as shown in Figure 19.

[0241] When the recruiter device 200 receives an operation from the recruiter to view the applicant's evaluation, it executes a viewing request process (step S17A). In the viewing request process, the recruiter device 200 sends the viewing request to the evaluation output unit 152 of the sharing server 100. In response to the viewing request, the evaluation output unit 152 selects from the evaluation summary database 127 an applicant evaluation summary for which the recruiter (viewer requester) is granted viewing rights (step S1521A).

[0242] Recruiters who request to view the data are authorized to view applicant evaluation summaries covering the entire company to which they belong, and applicant evaluation summaries covering the department to which they belong. Recruiters who request to view the data are not authorized to view any other evaluation summaries. The evaluation output unit 152 determines the viewing rights based on the member ID of the recruiter 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 reception unit 151, to identify the affiliation (company and department) and viewing rights of the person accessing the sharing server 100."

[0243] The evaluation output unit 152 selects an applicant evaluation summary corresponding to the viewing permission from the evaluation summary database 127. The evaluation output unit 152 transmits the data, including the selected applicant evaluation summary, to the recruiter device 200 (step S1522A). The transmitted data includes the applicant evaluation summary, as well as the applicant's (person being evaluated's) member ID, information about the company the applicant belongs to, information about the department the applicant belongs to, etc. Depending on the viewing request, the transmitted data may include applicant evaluation summaries corresponding to each of multiple applicants (persons being evaluated).

[0244] Upon receiving the applicant evaluation summary, the recruiter device 200 displays the applicant evaluation summary on the display 205 along with information about the company to which the applicant belongs and information about the department to which the applicant belongs (step S18A). If the recruiter device 200 receives applicant evaluation summaries corresponding to multiple applicants (those being evaluated), it displays the applicant evaluation summaries for all multiple applicants (those being evaluated) in a list.

[0245] Thus, when the sharing server 100 receives a viewing request in a communication established using 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's device 200 of the recruiter that sent the viewing request.

[0246] [Process for searching for members (applicants)] Next, referring to Figure 19, we will explain the processes in steps S4A, S19A, and S1431A to S1433A.

[0247] When the recruiter device 200 receives a search request from a recruiter, it performs a member search process to retrieve information about applicants (step S4A). In the member search process, the recruiter device 200 sends a search request to the member search unit 143 of the sharing server 100. The search request includes a criterion value for excluding members with low applicant ratings from the search. This criterion value is determined, for example, based on the applicant rating summary.

[0248] Upon receiving the search request, the member search unit 143 identifies the company to which the recruiter who submitted the search request belongs (step S1431A). Here, the company identified by step S1431A is referred to as "Company Xa".

[0249] The member search unit 143 identifies the recruiter operating the recruiter device 200 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 using the company database 121 and the member database 122.

[0250] Next, the member search unit 143 extracts members from the evaluation summary database 127 whose applicant evaluation summary value for the entire identified company Xa exceeds a certain threshold (step S1432A). In other words, the member search unit 143 extracts the search results by excluding members whose evaluation of the entire company Xa is low.

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

[0252] The sharing server 100 may be provided with a function to receive the setting information of the reference value from the recruiter device 200 of each company. Thereby, each company can exclude members with a low evaluation based on its own reference value from the search results.

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

[0254] As a result, the recruiter can view the search result from which members with a low overall evaluation of the company to which the recruiter belongs are excluded on the display 205. Therefore, when the recruiter selects an order winner from the applicants, the recruiter can save the trouble of visually excluding members with a low overall evaluation of the company.

[0255] In this embodiment, even if a member has a low evaluation in a certain department of the company to which the recruiter belongs, as long as the overall evaluation of the company is not low, the member is not excluded from the search results. However, the member search unit 143 may further exclude such members from the search results.

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

[0257] [Process to output a summary of applicant evaluations] First, we will explain the processes in steps S17B, S18B, S1521B, and S1522B, as shown in Figure 20.

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

[0259] Applicants who request to view the information are authorized to view the recruiter evaluation summary for the entire company to which they belong, and the recruiter evaluation summary for the department to which they belong. Applicants who request to view the information are not authorized to view any other evaluation summaries. The evaluation output unit 152 determines the viewing rights 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 the sharing server 100, including the evaluation reception unit 151, can use to identify the affiliation (company and department) and viewing rights of the person who accesses the sharing server 100."

[0260] The evaluation output unit 152 selects the recruiter evaluation summary corresponding to the viewing privileges from the evaluation summary database 127. The evaluation output unit 152 transmits the 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 recruiter's (evaluated person's) member ID, information about the company to which the recruiter belongs, information about the department to which the recruiter belongs, etc. Depending on the viewing request, the transmitted data may include recruiter evaluation summaries corresponding to each of multiple recruiters (evaluated people).

[0261] When the applicant device 300 receives the applicant evaluation summary, it displays the applicant evaluation summary on the display 305 along with information about the company to which the applicant belongs and information about the department to which the applicant belongs (step S18B). If the applicant device 300 receives applicant evaluation summaries corresponding to each of multiple applicants (those being evaluated), it displays the applicant evaluation summaries for the multiple applicants (those being evaluated) in a list.

[0262] Thus, when the sharing server 100 receives a viewing request in a 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.

[0263] [Process for searching for members (recruiters)] Next, referring to Figure 20, we will explain the processes in steps S4B, S19B, and S1431B to S1433B.

[0264] When the applicant device 300 receives a search request from an applicant, it performs a member search process to retrieve information about recruiters (step S4B). In the member search process, the applicant device 300 sends a search request to the member search unit 143 of the sharing server 100. The search request includes a criterion value for excluding members with low recruiter ratings from the search. This criterion value is determined, for example, based on the recruiter rating summary value.

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

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

[0267] Next, the member search unit 143 extracts members from the evaluation summary database 127 whose recruiter evaluation summary value for the entire identified company Xb exceeds a certain threshold (step S1432B). In other words, the member search unit 143 extracts the search results by excluding members whose evaluation of the entire company Xb is low.

[0268] The sharing server 100 may be equipped with a function to receive setting information for standard values ​​from each company's recruiting device 200. This allows each company to exclude members with low ratings based on their own standard values ​​from the search results.

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

[0270] As a result, applicants can view search results on display 305 that exclude members whose companies have a low overall rating. Therefore, when applicants select a contractor from among the recruiters, they can avoid the trouble of manually excluding members whose companies have a low overall rating.

[0271] In addition, in the present embodiment, even if a member has a low evaluation in a certain department of the company to which the applicant belongs, if the evaluation of the entire company is not low, the member is not excluded from the search results. However, the member search unit 143 may further exclude such a member from the search results.

[0272] [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 unit 127A shown in FIG. 9 as an example among the evaluation summary database 127.

[0273] The recruiter evaluation summary unit 127A shown in FIG. 21 includes evaluation summaries of each of Company B and Company C for the member P1 who acts as a "recruiter". The member P1 belongs to Company A. The evaluation summary of Company B is classified into "Overall", "System Department", and "Planning Department". The evaluation summary of Company C is classified into "Overall" and "Planning Department", etc. Members belonging to Companies B and C view the evaluation summary for the member P1 as "applicants".

[0274] 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. 21.

[0275] The viewing authority for the evaluation summary calculated from the evaluation of the System Department of Company B is granted to members of the System Department of Company B, but not to members other than the System Department of Company B. The viewing authority for 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.

[0276] The viewing authority for the evaluation summary calculated from the overall evaluation of Company C is granted to all members belonging to Company C. The viewing authority for 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 the Planning Department of Company C.

[0277] In the above, the scope of viewable information was explained using the applicant evaluation summary section 127A as an example. In matching system 1, the scope of viewable information for the applicant evaluation summary section 127B (see Figure 9) is also determined by the same design philosophy as the applicant evaluation summary section 127A.

[0278] If the viewers are members of Company X's first division and members of Company X's second division, the viewers' access 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 an applicant is a "viewer," the content they can view is the evaluation summary of the "recruiter." Conversely, when a recruiter is a "viewer," the content they can view is the evaluation summary of the "applicant."

[0279] Members belonging to the first division of company X can view the overall evaluation summary of company X and the evaluation summary of the first division of company X, but cannot view the evaluation summary of the second division of company X. Members belonging to the second division of company X can view the overall evaluation summary of company X and the evaluation summary of the second division of company X, but cannot view the evaluation summary of the second division of company X. Members belonging to company Y other than company X cannot view the overall evaluation summary of company X, the evaluation summary of the first division of company X, and the evaluation summary of the second division of company X.

[0280] The overall evaluation summary for Company X, the evaluation summary for Company X's first department, and the evaluation summary for Company X's second department will not be disclosed to members of companies other than Company X. Therefore, a member belonging to Company Y and acting as an applicant can objectively evaluate recruiters belonging to Company X without considering the relationships between the companies. Similarly, a member belonging to Company Y and acting as a recruiter can objectively evaluate applicants belonging to Company X without considering the relationships between the companies.

[0281] Furthermore, evaluations conducted by members of Company X (evaluations of recruiters and evaluations of applicants) are shared within Company X as recruiter evaluation summaries and applicant evaluation summaries. This helps evaluators understand that the accumulation of each evaluation generates useful information. This in turn motivates evaluators to conduct accurate evaluations.

[0282] As a result, the accuracy of both the recruiter evaluation summary and the applicant evaluation summary will improve. This will allow the recruiter evaluation summary to be used as useful reference data when selecting recruitment projects. Similarly, the applicant evaluation summary will be used as useful reference data when selecting contractors.

[0283] Furthermore, according to this embodiment, when the recruiter device 200 performs a member search process (step S4A), the recruiter is provided with search results that exclude members with low ratings (step S1432A). Similarly, when the applicant device 300 performs a member search process (step S4B), the recruiter is provided with search results that exclude members with low ratings (step S1432B). In other words, the matching system 1 is equipped with a filtering function that provides search results that exclude members with low ratings.

[0284] Therefore, recruiters can prevent mistakenly hiring low-rated members when deciding on contractors for their recruitment work, on a company-by-company basis. Similarly, applicants can prevent mistakenly selecting work offered by low-rated members when deciding which work to apply for from among many recruitment opportunities, on a company-by-company basis. The sharing server 100 may also perform filtering using evaluation summaries at the departmental level.

[0285] The recruiter device 200 may send a command signal to the sharing server 100 to instruct whether to use filtering using an evaluation summary for the entire company or filtering using an evaluation summary for each department. In this case, the sharing server 100 is provided with a function to change the evaluation summary used for filtering according to the command signal.

[0286] [Example of how disclosure scope is set according to the disclosure level] Figure 22 shows an example of how the scope of disclosure is set according to the disclosure level. Here, we consider the case where companies A through E form a community relationship, as shown in Figure 22, and company F does not form a community relationship with any of the companies. In this case, the scope of disclosure of the recruitment project will be as shown in Table 402, according to the company to which the recruiter belongs and the disclosure level set by the recruiter.

[0287] The disclosure levels "Level 1" to "Level 3" shown in Figure 22 correspond to the three levels already explained: "Our Company," "Within the Community," and "All." Therefore, at Level 1, the recruiter's job postings are disclosed only to applicants from the same company to which the recruiter belongs. At Level 2, in addition to the scope of Level 1, the recruiter's job postings are disclosed to applicants from companies that have a community relationship with the recruiter's company. At Level 3, the recruiter's job postings are disclosed to applicants from all companies, including the recruiter's company. However, if the recruiter specifies a company ID to be kept confidential, the company corresponding to that company ID will be excluded from the list of companies subject to disclosure, regardless of the set disclosure level. Of the disclosure levels in this embodiment, "Level 1" corresponds to "allowing the disclosure of business information to the first applicant and prohibiting the 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 belonging to either Group 1 or community groups with which a community relationship has been formed with Group 1, while prohibiting the disclosure of business information to applicants who do not belong to either Group 1 or any community group." "Level 3" corresponds to "allowing the disclosure of business information to applicants regardless of the group to which they belong."

[0288] Here, levels 1 to 3, as examples of multiple disclosure levels, have been explained. However, the number of disclosure levels is not limited to these. For example, a community may be divided into multiple subcommittees, and the decision of whether or not to disclose recruitment activities may be set for each subcommittee. More specifically, community 02 shown in Figure 5 may be divided into a first subcommittee and a second subcommittee. Company C belongs to the first subcommittee, and companies D and E belong to the second subcommittee. In this case, recruiters of company D may be allowed to choose whether to limit the scope of their recruitment activities to the scope of the first subcommittee or the scope of the second subcommittee.

[0289] The sharing server 100 may accept an operation to set the disclosure scope differently for each recruitment project. For example, using projects 001 to 003 from among many recruitment projects as examples, a concrete example of setting the disclosure scope differently for each recruitment project will be explained.

[0290] For example, the scope of disclosure for recruitment offer 001 may be limited to companies A and C belonging to the community identified by community ID=03. Alternatively, the scope of disclosure for recruitment offer 002 may be limited to companies C, D, and E belonging to the community identified by community ID=02. Alternatively, the scope of disclosure for offer 003 may be limited to companies C, D, and E belonging to the community identified by community ID=02, and companies A and C belonging to the community identified by community ID=03.

[0291] 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 Figure 22, Company A may form a community with Company Z identified by community ID=Z. For example, if a recruiter belongs to Company A, the recruiter may disclose its job postings to applicants belonging to Company A and applicants belonging to Company Z. Such a level of disclosure may be adopted as a variation of "Level 3" as shown in Figure 22.

[0292] In this case, "Level 3" corresponds to "allowing the disclosure of business information to applicants belonging to a specific community group (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, while prohibiting the disclosure of business information to applicants who do not belong to either the first group or the specific community group."

[0293] Here, levels 1 to 3 have been described as an example of multiple levels, but many more levels may be set as multiple types of disclosure levels. As an example of an interface for recruiters to set the scope of disclosure, a screen displaying checkboxes for selecting a desired level from among multiple types of levels may be displayed on the user device 500.

[0294] [Example of a screen displayed when checking your side job status] Figure 23 shows the screen displayed on the applicant device 300 used by the administrator (applicant's supervisor) when checking the status of their subordinate's side job. Figure 23 shows an example where the administrator's subordinate's side job status is displayed on the applicant device 300 (user device 500). The applicant device 300 is equipped with a keyboard 306A and a mouse 306B as operating units.

[0295] Here, the administrator is, for example, the head of the sales department at company C. Display 305 shows the status of side jobs held by employees in the sales department. The administrator can check the status of side jobs held by employees in the sales department by selecting one of the tabs 307A, 307B, 307C, etc., using the keyboard 306A or mouse 306B. Therefore, the administrator can manage the working hours of their subordinates to prevent them from becoming overworked. The progress rate may also be displayed on the screen.

[0296] [Example of a screen displayed when changing browsing restriction settings] Figure 24 shows the screen displayed on the applicant device 300 when the administrator changes the viewing restriction settings. Here, the administrator operating the applicant device 300 (user device 500) is assumed to belong to company D. As shown in Figure 24, the display 305 shows a list of job postings currently being recruited for company D. The display 305 also shows that company D has formed community relationships with companies C and E.

[0297] The list of business projects includes information related to each project, such as the "Project ID," "Recruiting Company ID," "Recruiting Company Name," and "Project Title." Figure 24 shows multiple projects from Company C and a project from Company F as examples of business projects. The list of business projects also includes a settings area where administrators can set "viewing restrictions" for each project.

[0298] The administrator can use mouse 306B to move cursor 308 to the settings area and switch the viewing restriction setting between "ON" and "OFF" in the settings area. "OFF" corresponds to no viewing restriction, and "ON" corresponds to viewing restriction. The "ON" setting is an example of restriction information for restricting viewing. The default setting in the settings area is "OFF". When the viewing restriction setting is switched from "OFF" to "ON", all employees belonging to company D will no longer be able to view business cases corresponding to "ON".

[0299] Figure 24 shows an example where the viewing restriction setting for company C's business project corresponding to "Project ID=011" is set to ON. By switching the viewing restriction setting for company C's business project corresponding to "Project ID=011" from OFF to ON, all employees belonging to company D will no longer be able to view company C's business project corresponding to "Project ID=011".

[0300] Since companies C and D have a community relationship, it is understood that they are not in a competitive relationship. Based on this understanding, company C would likely be happy to allow employees of company D to view and apply for its business projects. However, depending on the content of the business project or the company's circumstances, company D may have concerns about its employees accepting business projects from company C.

[0301] For example, if there is a risk that know-how held by company D could be leaked to company C through an employee of company D handling a specialized project for company C, company D would likely want to avoid having its employees apply for such a project. Alternatively, if company C's reputation in the industry has recently deteriorated, company D might want to avoid having its employees apply for projects from company C for a while.

[0302] Therefore, matching system 1 is equipped with a function that allows applicants to set restriction information for job postings to limit viewing. Applicants set restriction information for job postings they wish to restrict viewing. As a result, all employees of the company to which the applicant belongs will not be able to view the job postings for which restriction information has been set.

[0303] Recruiters are not notified which of the multiple job postings has restricted information set for it. Therefore, recruiters understand that there are no applications from applicants belonging to a particular company, but they do not think that their access to the job posting is restricted. Consequently, even if, for example, company D sets restricted information for company C's job posting, this does not cause any problems in the community relationship between company C and company D.

[0304] This example illustrates how viewing restrictions can be set for each individual case. However, the system can also be configured to set viewing restrictions collectively for companies or case types (e.g., sales cases). In this case, if a case is added after viewing restrictions have been set and it meets the conditions of the existing viewing restrictions, the system can be configured to immediately restrict viewing to that newly added case as well. Furthermore, the scope of viewing restrictions can be limited to the entire company or to specific departments specified when setting the restrictions. This allows users to, for example, have cases not displayed to research departments that handle confidential information, but to other departments such as general affairs.

[0305] [Timing Chart] Figure 25 is a timing chart showing the process involved in setting restriction information. Here, using companies C to E, where community relationships have been formed, as examples, we will explain the flow of setting viewing information for business cases.

[0306] Company C is a user (recruiter) providing job opportunities. Companies D and E are users (applicants) authorized by Company C to view job opportunities. In the following description, Company D's user device 500 is an example of a first user device operated by a first user belonging to the first group. Also, Company C's user device 500 is an example of a second user device operated by a second user.

[0307] First, the user device 500 of company C sets up business cases and disclosure information in response to user operations (step S101). Next, the user device 500 of company C transmits the business cases and disclosure information to the sharing server 100 in response to user operations (step S102). Note that the user may set up two or more business cases, or just one business case, in step S101.

[0308] Next, the sharing server 100 registers the received job postings in the job posting database 124 (step S103). Next, the sharing server 100 sets the scope of disclosure based on the received disclosure information (step S104). Here, it is assumed that the scope of disclosure of the job postings is limited to the "community" by the disclosure information. In this case, the job postings are disclosed only to companies D and E. In this way, the sharing server 100 sets the scope of disclosure of the job postings provided by the second user (a user belonging to company C) based on the disclosure information indicating the scope of disclosure of the job postings. Here, steps S103 and S104 are an example of a setting unit that accesses the database in which the job postings are registered and sets the job postings to be disclosed to the first group to which the first user belongs, based on the disclosure information indicating the scope of disclosure of the job postings.

[0309] The sharing server 100 discloses business cases to companies D and E according to the configured disclosure scope (step S105). Company E's user device 500 acquires business cases in response to user operations (step S106). Company E's user device 500 displays the acquired business cases (step S107). Company D's user device 500 acquires business cases (step S108). Company D's user device 500 displays the acquired business cases (step S109).

[0310] Next, the user device 500 of company D signs up to the sharing server 100 in administrator mode in response to the user's operation (step S110). Next, the user device 500 of company D sets restriction information in response to the user's operation (step S111). For example, as shown in Figure 24, the user selects the business case for which they want to restrict viewing and switches "OFF" to "ON" in the setting area. Step S111 is an example of a reception unit that receives user operations to input restriction information.

[0311] Next, the user device 500 of company D transmits restriction information to the sharing server 100 in response to user operations (step S112). Here, restriction information is transmitted to the sharing server 100 for each business case. Step S112 is also an example of a transmission unit that transmits restriction information to a compute device when a user operation is received by the reception unit.

[0312] For example, if restriction information is set for the first of two business cases, the restriction information for the first case is sent to the sharing server 100. Alternatively, if restriction information is set for the second of two business cases, the restriction information for the second case is sent to the sharing server 100. In other words, the user device 500 is configured to selectively send restriction information for the first case and restriction information for the second case to the sharing server 100 based on the user's operation.

[0313] Next, the sharing server 100 receives restriction information (step S113). Step S113 is an example of a receiving unit that receives restriction information from a user device. Next, the sharing server 100 changes the scope of disclosure of the business case based on the received restriction information (step S114). More specifically, the sharing server 100 registers restriction information in the recruitment case database 124 to restrict users of company D from viewing the target business case.

[0314] Step S114 is an example of a restriction section that restricts the disclosure of business opportunities to the first group according to the restriction information, regardless of the scope of disclosure set based on the disclosure information. Note that in step S1452 of Figure 15, if the applicant is a user of company D, business opportunities for which restriction information has been set are excluded from the business opportunities that can be disclosed.

[0315] Next, the sharing server 100 discloses the business opportunity only to users of company E (step S115). As a result, the business opportunity is not disclosed to users of company D. In this way, regardless of the scope of disclosure set based on the disclosure information, the sharing server 100 restricts the disclosure of business opportunities provided by the second user (a user belonging to company C) to the first group (company D) according to the restriction information. Restriction information is an example of information that restricts the disclosure of business opportunities to the first group to which the first user belongs, regardless of the scope of disclosure based on the disclosure information.

[0316] [Project Details] Figure 26 shows the details of the job postings included in the job posting database 124. The job postings include the application requirements. As shown in Figure 26, the job postings are registered in the job posting database 124 by job posting ID.

[0317] The job description includes the job name, job details, job registrant, and job registrant company. The job name is the title of the job posting. The job details include a description of the job posting. This description may include the skills, experience, and qualifications required of applicants. The job registrant is the person who registered the job, i.e., the recruiter. The job registrant company is the company to which the job registrant belongs.

[0318] The details of the job postings are made public to users (applicants) who are authorized to access the postings. The text included in the job posting details may contain internal company terminology. Such internal company terminology is registered in the job posting database 124 as "index information" so that it can be linked to the internal company terminology in the internal company terminology database 136, which will be described later.

[0319] As already explained using Figure 1, the user device 500 displays internal company terminology in a different format from other terminology. This allows the user to understand that it is internal company terminology. Furthermore, the user device 500 displays the intended meaning of the internal company terminology in response to user actions (for example, clicking on the internal company terminology section).

[0320] Applicants review the project details and decide which projects they wish to apply for from among many available. Before finally applying for a project, applicants may conduct interviews with the project's recruiter as needed. The recruiter may also select a specific applicant as a provisional contractor and conduct an interview with the provisional contractor before signing a service contract. After signing a service contract with an applicant, the recruiter may conduct interviews with the applicant (contractor) regarding the work details as the project progresses.

[0321] The user device 500 may provide the recruiter and applicant with a web conferencing environment for conducting these interviews. If a document containing company terminology is displayed on the display during a web conference, the user device 500 may display the company terminology in the manner shown in Figure 1.

[0322] [Other databases] In the following, in addition to the various databases 121 to 127 shown in Figure 2, other databases used in this embodiment will be described.

[0323] Figure 27 shows an example of the profile database 129. As shown in Figure 27, the profile database 129 registers member (user) profile information 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). Affiliation information is an example of group information that identifies either the company or a department within the company.

[0324] Furthermore, profile information includes member competency information. Member competency information is categorized by skills, experience, and qualifications.

[0325] Figure 28 shows an example of the internal terminology database 137. As shown in Figure 28, the internal terminology database 137 registers internal terminology information by company ID. The sharing server 100 identifies internal terminology by company by referring to the internal terminology database 137.

[0326] Internal terminology information includes affiliation information that can identify the member's affiliation (company and department). Affiliation information is an example of group information that identifies either the company or a department within the company. Affiliation information can also be said to indicate the company and department where the registered internal terminology is widely used.

[0327] Internal terminology information further includes the "name," "pronunciation," and "meaning" of the term being registered. For example, in the case of the internal term "DX," "DX" is registered as the "name," "Dee-ex" is registered as the "pronunciation," and "the meaning" is registered as "creating some kind of new value, whether or not digital technology is used."

[0328] Another example of internal company terminology is "app development." Generally, "app development" is understood to mean developing applications used on electronic devices such as smartphones. However, in a certain department within a company that handles electronic components, "app development" might mean "developing new applications for components." In such a case, the term "app development" and its meaning (developing new applications for components) would be registered in the internal terminology database 137.

[0329] [Explanation of processing procedures related to the indexing function] Next, various processing procedures related to the indexing function will be explained with reference to Figures 29 to 32. Figure 29 is a flowchart showing the processing procedures related to the indexing function of matching system 1.

[0330] In the flowchart shown in Figure 29, first, the sharing server 100 registers internal company terminology in the internal company terminology database 137 (step Sw1). In step Sw1, the sharing server 100 functions as an internal company terminology registration unit. Next, the sharing server 100 registers recruitment requests in the recruitment request database 124 (step Sw2). In step Sw2, the sharing server 100 functions as a request registration unit. When the request registration unit registers recruitment requests in the recruitment request database 124, it indexes the internal company terminology included in the recruitment request information.

[0331] Next, the sharing server 100 displays the indexed case information on the user device 500 (step Sw3). For example, if the text describing the case details uses internal company terminology, the text with the internal company terminology underlined will be displayed on the user device 500. Alternatively, or in addition to underlining the internal company terminology, the internal company terminology may be displayed on the screen 552 of the user device 500 in a different color from other words. In step Sw3, the sharing server 100 functions as a display unit.

[0332] Figure 30 is a flowchart showing the processing procedure of the internal terminology registration unit (Sw1). First, the person in charge at the company compiles internal terminology using the company's own system, etc. (Step Sw11). In other words, the person in charge creates something like an internal glossary. Next, the person in charge downloads a registration template from the sharing server 100 (Step Sw12). Next, the person in charge enters the necessary information into the template (Step Sw13). The necessary information includes the internal term, the meaning of the internal term, and the definition of the internal term.

[0333] Next, the company representative accesses the sharing server 100 and retrieves their 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 a template along with their profile information to the matching system 1 (step Sw15). The sharing server 100 retrieves the profile information and the template. Based on the retrieved profile information and template, the sharing server 100 generates internal terminology information and registers the generated internal terminology information in the internal terminology database 137 (step Sw16). As a result, internal terms and their meanings are registered in the internal terminology database 137. In addition, internal terms and their meanings are registered in the internal terminology database 137 for each company.

[0334] Steps Sw11 to Sw16 are executed for each company. As a result, company terminology information is registered in the company terminology database 137 for each company. Alternatively, the sharing server 100 may register company terminology in the company terminology database 137 in bulk from an external file such as a CSV (Comma Separated Value) file.

[0335] Figure 31 is a flowchart showing the processing procedure of the case registration unit (Sw2). First, a recruiter who wishes to register a recruitment case in the system accesses the profile database 129 to obtain their company information (step Sw21). Next, the recruiter inputs the case information into the user device 500 (step Sw22). The case information includes various information such as the details of the case which will be registered in the recruitment case database 124. The recruiter may input the details of the case using internal company terminology commonly used within their company.

[0336] Next, the sharing server 100 automatically searches for internal company terminology included in the entered project information (step Sw23). At this time, the sharing server 100 indexes the internal company terminology found through the search and links it to the internal company terminology information registered in the internal company terminology database 137. Next, the sharing server 100 registers the project information entered by the recruiter in the recruitment project database 124 (step Sw24). As a result, the project information is registered in the recruitment project database 124 with the internal company terminology and its meaning associated with it.

[0337] Figure 32 is a flowchart illustrating the processing procedure for displaying the meaning of internal company terminology on the screen in response to the applicant's actions. This section describes the process of providing matching job postings that are suitable for the applicant, taking into account the scope of disclosure for the job posting and their capacity for side work, and also explaining the meaning of internal company terminology to the applicant as needed.

[0338] First, the sharing server 100 receives a search request for job postings from an applicant (step Sw101). Next, the sharing server 100 determines the applicant's affiliation (step Sw102). Details of this process have already been explained in step S1451.

[0339] Next, the sharing server 100 extracts projects that can be disclosed (step Sw103). The details of this process have already been explained in step S1452. Next, the sharing server 100 extracts projects that can be handled with the applicant's spare time for side jobs (step Sw104). The details of this process have already been explained in step S1453. Note that the process in step Sw104 may be deleted from this flowchart. In other words, the sharing server 100 may extract projects that match the applicant without considering the applicant's spare time for side jobs.

[0340] Next, the sharing server 100 extracts matching cases (step Sw105). Details of this process have already been explained in step S1454. Next, the sharing server 100 transmits the matching cases (step Sw106). Details of this process have already been explained in step S1455. In this way, the sharing server 100 transmits the matching cases to the applicant device 300, thereby displaying the matching cases on the applicant device 300.

[0341] Next, the sharing server 100 detects a click operation of an internal term corresponding to a registered index (step Sw107). Next, the sharing server 100 refers to the internal term database 137 and sends the meaning of the internal term to the applicant device 300 (step Sw108). Next, the applicant device 300 displays the meaning of the internal term on the display 305 (step Sw109). As a result, for example, the screen 552 shown in Figure 1 is displayed on the display 305. In this way, the sharing server 100 displays the meaning of the internal term on the applicant device 300 by sending the meaning of the internal term to the applicant device 300.

[0342] As described above, according to this embodiment, a matching system 1 that functions as a crowdsourcing platform can be provided. In order to find more suitable personnel using crowdsourcing, it is desirable to broaden the scope of crowdsourcing rather than limiting it to a specific company or a small number of companies. In this case, it becomes necessary to consider the interests of the recruiter who is looking for contractors for the work and the applicant who applies for that recruitment. In this embodiment, the sharing server 100 communicates with the applicant device 300, which is operated by the applicant, via the communication interface 104. The sharing server 100 registers the work information for which contractors are being sought and disclosure information indicating the scope of disclosure of the work information in the database (step S1442). The sharing server 100 determines, based on the disclosure information, which work information registered in the database 120 is permitted to be disclosed to the applicant (step S1452). The work information includes detailed information about the content of the work (project details (recruitment guidelines)). The sharing server 100 displays the meaning of terms (including in-house terms) contained in the business information and detailed information that is permitted to be disclosed to the applicant to the applicant device 300 (steps Sw3, Sw106, Sw109).

[0343] Therefore, according to this embodiment, it is possible to select appropriate applicants while taking into consideration the interests of the recruiter and the applicants. Furthermore, according to this embodiment, it is possible to prevent applicants from misunderstanding the content of job information due to unfamiliar or unusually used terminology.

[0344] Furthermore, according to this embodiment, users can reduce the effort required to provide supplementary explanations of internal terminology when exchanging project-related information with external users. In addition, the sharing server 100 can automatically index internal terminology included in project information. Therefore, users do not need to manually index internal terminology. Furthermore, the sharing server 100 has a function to register internal terminology in the internal terminology database 137. Therefore, users do not need to manually register internal terminology in the internal terminology database 137. Moreover, users can recognize that internal terminology may not be understood by other companies, thus enabling them to grasp cultural differences with other companies.

[0345] In this embodiment, "corporate terminology" used within a company was given as an example of "in-house terminology" that is widely used within the user's group. However, the embodiments described above may also be applied to terms similar to corporate terminology used in non-profit organizations, communities, and their units (departments, sections, etc.), either in place of or in addition to "corporate terminology."

[0346] In this embodiment, "company-specific groups" and "department-specific groups within the same company" are examples of "groups." Freelancers and other applicants not belonging to a company may form a single "group." Multiple companies may form a "company group."

[0347] In this embodiment, "companies that form community relationships" is an example of a "community group."

[0348] In this embodiment, the "non-disclosure subject" information included in the disclosed information is an example of "information that can identify persons who are prohibited from disclosing business information."

[0349] The communication (S9 in Figure 11) from the administrator's applicant device 300, which functions as an approver, to the approval unit 147 to transmit approval information takes place on a logical communication path identified by the approver's member ID. "The approval unit 147 receiving approval information on such a communication path" is an example of "receiving an approval notification in a communication that includes the identification information of the first applicant's approver."

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

[0351] 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 operated by one or more evaluators belonging to the first group."

[0352] 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 operated by one or more evaluators belonging to a second group different from the first group."

[0353] Figure 21 illustrates two departments of company A: the Systems Department and the Planning Department. In this embodiment, "one of the Systems Department and the Planning Department" is an example of a "first division group" included in the first group, and the other is an example of a "second division group" included in the first group.

[0354] The sharing server 100 extracts job information from the list of job postings database 124 in which the applicant's working hours will not exceed the maximum hours, based on the estimated man-hours registered in the job posting database 124, the maximum hours for side jobs registered in the company database 121, the actual hours for side jobs registered in the side job database 125, and the estimated hours for side jobs registered in the side job database 125. Specifically, for example, if an applicant is engaged in multiple side jobs, the sharing server 100 calculates the total actual hours for side jobs corresponding to each side job to determine the total actual hours for side jobs, and calculates the total estimated hours for side jobs corresponding to each side job to determine the total estimated hours for side jobs. The sharing server 100 adds the calculated total actual hours for side jobs and total estimated hours for side jobs to determine the total hours for side jobs. The sharing server 100 subtracts the total hours for side jobs from the applicant's maximum hours for side jobs to determine the applicant's available hours for side jobs. The sharing server 100 searches the list of job postings database 124 for jobs that can be handled with the calculated available hours for side jobs. At this time, the sharing server 100 calculates the time required to handle each recruitment request based on the estimated man-hours in the recruitment request database 124 and searches for recruitment requests that fall within the range of available time for side work. Here, "maximum time for side work" is an example of "maximum time which is the upper limit of the applicant's working hours," "actual time for side work" is an example of "actual time which is the time the applicant has already worked as actual work," and "expected time for side work" is an example of "expected time which is the time expected to be the applicant's working hours." The maximum time may be set not only for side work, but also for the total time of main work and side work combined. The first maximum time may be an upper limit that applies to all work, including both main work and side work, rather than just the maximum time for side work. The first actual time and the first expected time may be the total time of all work, including both main work and side work, combined, rather than just the time for side work.

[0355] The recruiter device 200 and applicant device 300 are not limited to those equipped with a processor, memory, communication interface, and input / output interface as shown in Figure 2, but may also be thin client systems utilizing VDI (Virtual Desktop Infrastructure). A thin client system utilizing VDI is a system that transfers and uses a desktop environment located on a server to a terminal in a remote location. The recruiter device 200, applicant device 300, and sharing server 100 do not necessarily have to be independent devices. When using such a thin client system, the functions of the recruiter device 200, applicant device 300, and sharing server 100 can be provided on the same aggregation server.

[0356] Database 120 is not limited to relational databases; object-oriented databases, NoSQL databases, and other types of databases may also be used.

[0357] Sharing Server 100 is an example of a compute device. A compute device may also be configured using servers (on-premise servers, cloud servers, etc.) or serverless systems. Here, an on-premise server is a server installed and managed within facilities managed by the company itself. A cloud server is a server provided by another company via a network (a leased server). A serverless system is a system that allows users to utilize compute and memory functions only when needed, without being aware of the existence of a server. A compute device includes servers and serverless systems. Servers include on-premise servers and cloud servers.

[0358] <Example 1> Next, we will explain Modification 1 with reference to Figure 33. Figure 33 is a flowchart of the processing of restriction information performed by the sharing server 100 as Modification 1. Regarding the setting of restriction information, Figures 24 and 25 were used to introduce an example in which restriction information is set for each business case.

[0359] However, when there are many business cases that require viewing restrictions, setting restriction information for each business case becomes a significant burden on the user. Furthermore, it becomes difficult for the user to reliably set restriction information for all business cases that should be restricted. Therefore, in Modification 1, we will explain an example in which the user specifies the company that provides the business cases to which they want to restrict viewing, or the industry of that company (for example, the electronic components industry), and restriction information is set for business cases corresponding to the specified company or industry.

[0360] In order to implement Modification 1, the operator of Matching System 1 registers, in addition to a company ID for identifying companies, an industry ID for identifying the industry of a company in both the company database 121 (Figure 3) and the job posting database 124 (Figure 5).

[0361] First, a user belonging to an applicant company signs up for the sharing server 100 in administrator mode, and then enters the name of the company or the industry of the company for which they want to set restriction information into the user device 500. The entered company name is an example of user-specified information and company-specified information. The entered industry is an example of industry-specified information.

[0362] For example, consider a case where a user belonging to company D sets restriction information for all business cases provided by company C. In this case, company D is an example of the first group, and company C is an example of the second group. The user belonging to company D (first user) inputs the company name of company C into user device 500. The "company name of company C" entered into user device 500 is an example of user-specified information. In this way, user-specified information includes information that specifies the second group.

[0363] Furthermore, the user may specify not only for-profit organizations such as corporations, but also non-profit organizations and communities that use Matching System 1 as the organizations for which they wish to set restriction information. Alternatively, if there are members who use Matching System 1 as individuals without belonging to an organization, the user may input the names of such individual members into the user device 500. In other words, the targets specified by the user-specified information may be for-profit organizations, non-profit organizations, or individuals.

[0364] The user device 500 transmits the entered company name or industry information to the sharing server 100 as restriction information. The sharing server 100 accepts the restriction information setting from the user device 500 (step S120).

[0365] Next, the sharing server 100 refers to the job posting database 124 and searches for job postings that match the restriction information from among the multiple job postings that are disclosed to users (step S121). Job postings that match the restriction information are those registered with a company ID corresponding to the company name received in step S121. Alternatively, job postings that match the restriction information are those registered with an industry ID corresponding to the industry name received in step S121.

[0366] Next, the sharing server 100 sets "restriction information" in the job posting database 124 so that the job postings found in the search in step S121 are excluded from the scope of disclosure (step S122).

[0367] Next, a user belonging to the applicant company signs up to the sharing server 100 in general mode and then requests to view job postings from the sharing server 100. The sharing server 100 then receives the request to view job postings from the user via the user device 500 (step S123).

[0368] Next, the sharing server 100 sends the business cases to be disclosed to the user device 500, excluding those excluded by the restriction information (step S124), and terminates the processing based on this flowchart. The user device 500 displays the business cases to be disclosed, excluding those excluded by the restriction information.

[0369] In this example, we have described how restriction information is set using a company name or industry name as the key. However, the system may be configured to allow users to specify business cases for which they wish to set restriction information by combining multiple keys. For example, Matching System 1 may allow a user to specify the industry name for which they wish to set restriction information as the first key, and companies to be excluded from the setting of restriction information (e.g., venture companies, etc.) as the second key.

[0370] Furthermore, the matching system 1 may accept user operations such as specifying the industry of companies for which restriction information should be set, and also specifying that some companies within that industry should be excluded from the setting of restriction information. Note that industry is only one aspect of the category to be restricted. In addition to industry, or instead of industry, the restriction information may be composed of company names or department names (for example, intellectual property department).

[0371] <Modification 2> Next, we will explain Modification 2 with reference to Figures 34 to 36. Modification 2 describes a reverse offer function that allows recruiters to encourage individuals selected from a large number of members to participate in recruitment activities.

[0372] [Background for proposing the reverse offer function] In crowdsourcing, the recruiter typically discloses information about the job opening and waits for applications from those interested in the job. However, with this method, it may take time to receive responses from applicants. Furthermore, it is uncertain whether applicants with the skills the recruiter is looking for will apply.

[0373] Therefore, it is conceivable that recruiters could search for members and nominate suitable members (reverse offer). However, if recruiters are only informed of the member's ID and name, it would be difficult for them to nominate the applicant they truly desire. Furthermore, to prevent confidential information from being leaked to rival companies, member information of rival companies must be excluded from the search results.

[0374] In Modification 2, taking this background into account, the recruiter who performs a member search is provided with search results that include detailed member profile information. Furthermore, in Modification 2, member information of companies that are rivals of the recruiter's affiliated company is excluded from the search results. Modification 2 will be explained in detail below with reference to diagrams.

[0375] Figure 34 is a diagram illustrating the functions of the sharing server 100, recruiter device 200, and applicant device 300 related to Modification 2.

[0376] As shown in Figure 34, the sharing server 100 functionally includes, in addition to the member search unit 143, a reverse offer request unit 161, a reverse offer approval request unit 162, and a reverse offer request acceptance notification unit 163. These various functions are realized by the processor 101, memory 102, storage 103, and communication interface 104 provided in the sharing server 100.

[0377] As previously explained, the member search unit 143 has a function to search for members of the matching system 1. In particular, in the modified example 2, the member search unit 143 has a function to provide the searcher with detailed profile information of members. When the recruiter device 200 receives a search operation from a recruiter, it executes the member search process (step S21). In particular, in step S21, the recruiter device 200 accepts a search operation from 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 member information provided includes detailed profile information of the members. However, the member search unit 143 excludes member information of companies that are rivals to the recruiter's affiliated company, etc., from the search results.

[0378] The recruiter device 200 receives member information (search results) from the member search unit 143 and displays the member information as search results on the display 205 (step S22). Subsequently, the recruiter device 200 accepts an operation from the recruiter to select an applicant from the search results. That is, the recruiter selects a member to make a counter-offer to based on the search results and makes a counter-offer by operating the recruiter device 200 (step S23). The recruiter device 200 sends the member ID of the member targeted for the counter-offer to the sharing server 100.

[0379] The counter-offer request unit 161 receives the member ID of the member to be targeted for 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 to be targeted for the counter-offer that a request for a counter-offer has been received. This notification may include information about the recruitment project to be targeted for the counter-offer. The member to be targeted for the counter-offer receives the request for a counter-offer via the applicant device 300. The "request" received here is an example of "information that encourages applicants to apply". The member to be targeted for the counter-offer decides whether or not to accept the request for a counter-offer. The member to be targeted for the counter-offer can use the applicant device 300 to accept the request for a counter-offer or to reject the request for a counter-offer. For example, the applicant device 300 accepts the request for a counter-offer (step S24). Applicant device 300, which has accepted the request for a counter-offer, transmits the application information to the counter-offer approval request unit 162.

[0380] The reverse offer approval request unit 162 sends the applicant's application information to the applicant's supervisor. Based on the relationship between the applicant's member ID and the supervisor's member ID registered in the member database 122, the reverse offer approval request unit 162 identifies the supervisor's member ID, who is the applicant's administrator. The applicant's supervisor checks the application information on their applicant device 300 and approves the application (step S25).

[0381] The reverse offer request acceptance notification unit 163 receives approval information from the applicant's supervisor. The reverse offer request acceptance notification unit 163 accepts the applicant's application, conditional on receiving the approval information. The reverse offer request acceptance notification unit 163 notifies the recruiter device 200 that an application from the member who made the reverse offer has been accepted. Based on this notification, the recruiter device 200 notifies the recruiter that the reverse offer has been accepted (step S26). More specifically, the recruiter device 200 displays information on the display 205 to notify the recruiter that the reverse offer has been accepted.

[0382] Figure 35 shows an example of the member database 122A related to the modified example 2. Compared to the member database 122 shown in Figure 4, the member database 122A shown in Figure 35 includes profile information and profile disclosure information indicating whether or not the profile is to be made public.

[0383] Matching System 1 grants members the authority to register and modify their profile information in the member database 122A using the applicant device 300. Members register various profile information in the member database 122A using the applicant device 300. This profile information includes, for example, the member's SPI (Synthetic Personality Inventory) information, work history, achievements, and qualifications.

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

[0385] This section describes an example where the disclosure of a member's profile information is determined based on their profile disclosure settings. However, the sharing server 100 may also accept settings for disclosure on a per-type basis for each type of profile information. This allows, for example, a member to disclose their achievements and qualifications while keeping their SPI information private. Alternatively, if the profile information includes age, the member can keep their age private while disclosing the rest of their profile information. In this case, the sharing server 100 registers multiple profile information entries for multiple registrants (members) in the member database 122A. The sharing server 100 accepts input from each of the multiple registrants to set the scope of their multiple profile information entries to be disclosed as search results.

[0386] Figure 36 is a flowchart showing the processing procedure for the reverse offer member search process related to Modification 2. The processing based on this flowchart is executed by the sharing server 100.

[0387] First, the sharing server 100 receives a search request from a searcher to find a member suitable for their recruitment project (step S211). Here, the searcher is a recruiter with a recruitment project. The recruiter uses their recruiter device 200 to search for members who have the appropriate skills for the recruitment project and makes a counter-offer to them. 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 project ID of the recruitment project.

[0388] 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).

[0389] Next, the sharing server 100 identifies the disclosure level and non-disclosure company ID list of recruitment opportunities registered in the recruitment opportunity database 124 (step S214). Then, the sharing server 100 extracts members who can be disclosed to the searcher (step S215).

[0390] More specifically, the sharing server 100 identifies companies that should not disclose the job postings held by the searcher (recruiter) based on the list of non-disclosing companies and disclosure levels in the job posting database 124. The sharing server 100 determines that members belonging to such companies are members that cannot be disclosed to the searcher. The sharing server 100 extracts members other than those belonging to such companies as members that can be disclosed to the searcher.

[0391] Next, the sharing server 100 refers to the member database 122A and excludes the profile information of members who have set their profile information to private from the extracted member information (step S216).

[0392] Next, the sharing server 100 sends the extracted member information to the search request source (step S217), and the process based on this flowchart ends. The recruiter device 200, the search request source, receives the member information sent from the sharing server 100 and displays the information on the display 205. The information displayed on the display 205 includes the ID, name, and profile information of each extracted member. However, for members who have chosen not to disclose their profile information, only the member's ID and name are displayed, and the profile information is not displayed.

[0393] As explained above, according to Modification 2, recruiters can search for members they deem most suitable for the recruitment work by referring to the detailed profile information of the members, and then make a counter-offer to that member. Moreover, members from companies that are rivals of the recruiter's company and community are excluded from the search results. This prevents recruiters from inadvertently outsourcing work to members of such rival companies. Furthermore, since members can decide whether or not to make their profile information public, the system can be provided in a way that respects the free will of each member.

[0394] Furthermore, it may be possible to allow members to choose whether or not to disclose their name, in addition to their profile information. Additionally, several categories may be created within the profile information, allowing members to choose whether or not to disclose their profile information for each category.

[0395] By adding the offer function described above to Matching System 1, recruiters can view the profile information of members who are permitted to view job postings. Furthermore, recruiters can encourage applications from members they wish to place orders with. Members who are encouraged to apply by a recruiter can view the job information and accept or reject the application. In addition, when registering or editing member information, each member can decide whether or not to make their profile information public. This allows recruiters to proactively select potential clients and assign the most suitable applicants to work as quickly as possible.

[0396] <Variation 3> Next, we will explain Modification 3 with reference to Figures 37 to 41. Modification 3 describes a member group application function that allows multiple members to apply for recruitment work as a group.

[0397] [Background for proposing the member group application function] In crowdsourcing, typically, a recruiter discloses information about a project, and individuals interested in the project apply. However, many projects, such as comprehensive tasks ranging from business planning to acquiring related intellectual property rights, require or are best handled by a team of multiple people. Therefore, when the number of applicants is limited to one, it is difficult for those wishing to take on more work than they can handle individually.

[0398] In Modification 3, taking this background into account, a member group application function is provided that allows multiple members to apply for recruitment work as a group. Modification 3 will be explained in detail below.

[0399] Figure 37 is a block diagram showing the configuration of the sharing server 100, recruiter device 200, and applicant device 300 related to Modification 3. Compared to the block diagram shown in Figure 2, the block diagram in Figure 37 has an additional member group database 128. The recruitment database 124A shown in Figure 37 has a function added to the recruitment database 124 shown in Figure 6 that allows registration of recruitment projects that allow applications from member groups.

[0400] The member group database 128 contains member groups consisting of multiple members. Recruiters can use the recruiter device 200 to register recruitment opportunities that allow applications from member groups in the recruitment opportunity database 124A. Applicants can use the applicant device 300 to apply to recruitment opportunities that allow applications from member groups, using member groups registered in the member group database 128.

[0401] Figure 38 shows an example of the member group database 128 related to the modified example 3. The member group database 128 contains information about member groups. The member group information includes a group ID to identify 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.

[0402] Hereafter, using the group ID, the member groups corresponding to each group ID may be referred to as Member Group G1, Member Group G2, Member Group G3, and so on.

[0403] Member group G1 consists of three members identified by member IDs P1, P2, and P5. Since the company ID registered for member group G1 is 00A, it can be seen that all three members belong to company A.

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

[0405] Member group G3 consists of four members identified by member IDs P4, P7, P8, and P14. Since the company ID registered for member group G3 is 00C, it can be seen that all four members belong to company C.

[0406] The member group database 128 is stored in the storage 103 of the sharing server 100, as shown in Figure 37. Members form member groups with the consent of other members they have met through the same company or community, and register these member groups in the member group database 128. A "member group" is an example of an "application group".

[0407] Figure 39 shows an example of the recruitment database 124A related to the modified example 3. Compared to the recruitment database 124 shown in Figure 6, the recruitment database 124A shown in Figure 39 has additional information on the recruitment type. The recruiter operates the recruiter device 200 to set the recruitment type. The sharing server 100 registers the recruitment type based on that setting in the recruitment database 124A, associating it with the business information.

[0408] The recruiter can choose between group and individual recruitment methods. If the recruiter does not select a recruitment method, the recruitment method for the project will be considered not limited to either group or individual. Projects with the recruitment method set to group can only be undertaken by member groups. Projects with the recruitment method set to individual can only be undertaken by individual members. Projects with no restrictions on the recruitment method can be undertaken by either member groups or individuals. "Recruitment Method Information" means that "the work for which contractors are being recruited is considered to be multiple Applicants This is an example of "information that can identify that the job should be applied for jointly."

[0409] Figure 40 is a diagram illustrating the functions of the sharing server 100, recruiter device 200, and applicant device 300 related to Modification 3. In Figure 40, a determination unit 145A is added to the sharing server 100 compared to Figure 11. Also, in Figure 40, compared to Figure 11, step S7A is added after step S7, and step S8A for group applications is adopted instead of step S8 for applications.

[0410] Here, we assume that the applicant belongs to multiple member groups. The applicant operates the applicant device 300 to search for job postings (step S6). The applicant device 300 sends a search request to the job posting extraction unit 145 of the sharing server 100.

[0411] When the case extraction unit 145 receives a search request, it extracts cases from the recruitment cases registered in the recruitment case database 124 that are permitted for viewing by applicants, as explained with reference to Figure 11. The cases extracted by the case extraction unit 145 include cases where the recruitment type is "group," "individual," or "unrestricted." 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).

[0412] The display 305 shows the disclosure level, project title, estimated man-hours, estimated period, project details, and recruitment format for each recruitment project. If a member group wishes to apply, the applicant uses the operation unit 306, such as a mouse and keyboard, to specify the member group and select a project where the recruitment format is "group" or "unrestricted." The applicant device 300 accepts the member group and the project the applicant wishes to apply for based on the applicant's operation (step S7A). The applicant device 300 sends 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 obtains the group ID and project ID.

[0413] The determination unit 145A accesses the member group database 128 and identifies the member ID registered in accordance 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.

[0414] The determination unit 145A accesses the community database 123 to identify the community ID of the community to which the identified company ID belongs. The determination unit 145A accesses the recruitment database 124A to identify the company ID (recruiter's company ID), non-disclosure company ID, disclosure level, and recruitment type registered in correspondence with the acquired recruitment ID.

[0415] Based on the information identified as described above, the determination unit 145A determines whether the recruitment project received by the applicant device 300 is one that is permitted to be applied for by the member group specified by the applicant. In other words, the determination unit 145A determines whether or not to permit the application by the member group.

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

[0417] The determination unit 145A returns the determination result to the applicant device 300. Figure 40 shows the flow when the determination unit 145A approves the application by the member group. If the determination unit 145A approves the application by the member group, the applicant device 300 accepts the application from 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 acceptable, and a screen confirming whether or not to apply. The applicant selects to apply using the operation unit 306, such as a mouse and keyboard.

[0418] When the applicant device 300 receives an application from a member group (step S8A), it sends 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 described using Figure 11. However, the application unit 146 sends the application information to the supervisor of each member belonging to the member group. Therefore, the application approval process in step S9 is performed for each supervisor of each member belonging to the member group. Accordingly, the approval unit 147 receives approval information indicating approval of the subordinate's application, or rejection information indicating whether or not the subordinate's application is rejected, from multiple supervisors.

[0419] The approval unit 147 accepts an applicant's application only if it has obtained approval information from all of the supervisors of each member belonging to the member group. Upon receiving an applicant's application, the approval unit 147 transmits the application information to the recruiter device 200. As already explained using Figure 11, the recruiter device 200 displays the application details on the display 205 (step S10). The recruiter inputs the result of their decision to accept or reject the applicant to the recruiter device 200. The recruiter device 200 receives the input result (step S11) and transmits the accepted acceptance or rejection result to the notification unit 148 of the sharing server 100.

[0420] The notification unit 148 transmits the application results (acceptance or rejection) to the applicant's applicant device 300 and the supervisor's (administrator's) applicant device 300. However, the notification unit 148 also transmits the application results to the supervisor of each member belonging to the member group.

[0421] The applicant's applicant device 300 and the applicant device 300 of each member's supervisor belonging to the member group display the application results on the display 305 (steps S12, S13). The applicant and each member's supervisor belonging to the member group confirm the application results by looking at the display on the display 305.

[0422] Figure 41 is a diagram illustrating the procedure for registering a recruitment request related to Modification Example 3 in the recruitment request database 124A. Compared to Figure 13, Figure 41 includes the addition of a recruitment type to the business information entered into the recruiter device 200.

[0423] In Modification 3, when a recruiter registers a recruitment request, they can include the recruitment type of the request in the business information when inputting the business information and disclosure information of the recruitment request into the recruiter device 200. The recruitment type is either group or individual. The request registration unit 144 of the sharing server 100 registers the recruitment request in the recruitment request database 124A, including the recruitment type selected by the recruiter (step S1442). If the recruiter has not selected a recruitment type, the request registration unit 144 registers information in the recruitment request database 124A indicating that the recruitment type is not limited. The other contents shown in Figure 41 are the same as those in Figure 13 which have already been explained, so their explanation will not be repeated here.

[0424] As explained above, according to Modification 3, multiple members can apply for a job posting as a group. Furthermore, according to Modification 3, the decision on whether or not to approve a member group's application is based on the relationship between the recruiter's company and community and the companies and communities to which each member of the member group belongs. Therefore, Recruiter A group of members, including members belonging to an organization that is in a competitive relationship with that organization, Recruiter This prevents us from accepting unsolicited job offers.

[0425] By adding the member group application function described above to Matching System 1, it becomes possible to provide a system in which the receiving party can view job postings and apply to them as a member group. This enables Matching System 1 to handle the ordering and receiving of large-scale projects that are best handled by a team.

[0426] <Modification 4> Figure 42 shows the configuration of matching system 1A related to modification 4. As shown in Figure 42, the functions of the sharing server 100 may be distributed and deployed within the systems of each company. In other words, a distributed management type matching system 1A may be adopted as the matching system 1 instead of a centrally managed type matching system 1.

[0427] The system configuration shown in Figure 42 is common to companies A, B, C, D, etc. Each company is equipped with a user device 500, a database 520, and storage 503 to store 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.

[0428] The user device 500 is comprised of, for example, a server. The user device 500 is an example of a compute system 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, memory for storing programs necessary for the processor's calculations, and a communication interface.

[0429] Database 520 has the same functions as Database 120 shown in Figure 2, and includes a recruitment database 524 that replaces the recruitment database 124, as well as various other databases. The recruitment database 524 for Company A contains recruitment proposals submitted by employees of Company A acting as recruiters. The recruitment database 524 for Company B contains recruitment proposals submitted by employees of Company B acting as recruiters. Similarly, the recruitment databases 524 for other companies also contain recruitment proposals submitted by employees of each company acting as recruiters.

[0430] Database 520 contains the disclosure permission list 521. The disclosure permission list 521 includes a list of groups (companies, communities, etc.) that are permitted to disclose the recruitment information. The disclosure permission list 521 includes information corresponding to the "non-disclosure company ID list" and "disclosure level" from the information registered in the recruitment database 124 shown in Figure 6. The user device 500 registers the recruitment information (business information) and the disclosure permission list 521 (disclosure information) indicating the scope of disclosure of the recruitment information in database 520.

[0431] Company A's user device 500 determines, based on the disclosure permission list 521, which companies or communities to which to disclose the recruitment offer and which to which to not. Based on that decision, Company A's user device 500 transmits the recruitment offer to each company or community. For example, if Company A's user device 500 decides to disclose a recruitment offer to Company C but not to Companies B and D, it transmits the recruitment offer to Company C but not to Companies B and D.

[0432] Each user device 500 of companies B, C, D, etc., operates based on the disclosure permission list 521, just like the user device 500 of company A. In this way, the user device 500 determines, based on the disclosure permission list 521, which recruitment opportunities registered in the database 520 are permitted to be disclosed to applicants, and provides the recruitment opportunities permitted to be disclosed to applicants to the applicant device 300.

[0433] According to variation 4, it becomes unnecessary to have a server within the matching system for centralized system management.

[0434] <Modification 5> Modification 5 will be explained using Figure 43. Figure 43 is a diagram showing an example of applying Kerberos authentication to the matching system 1A (modification 5). As shown in Figure 43, Kerberos authentication may be applied to authentication between companies in the matching system 1A. Kerberos authentication is one of the network authentication methods applied between a server and a client.

[0435] Here, we will explain Modification 5 using companies A and C as examples from among several companies. As shown in Figure 43, company A has an authentication system 510A, and company C has an authentication system 510C. The authentication system 110 is a KDC (Key Distribution Center). The authentication system 110 is operated by, for example, a certification body. The authentication system 110 consists of servers located at the certification body. The authentication systems 510A and 510C consist of, for example, user devices 500 (see Figure 42).

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

[0437] This section describes an example where company A performs Kerberos authentication and then sends a job posting to company C. Therefore, in this example, company A is the recruiter, and company C is the applicant. First, the authentication system 510A requests authentication from the authentication system 110 (step Sk101). For example, the authentication system 510A sends the necessary authentication information, such as the login ID and password, to the authentication system 110's AS. The authentication system 510A may also use the public key authentication method for the authentication procedure.

[0438] The AS of authentication system 110 authenticates based on the information received from authentication system 510A and then sends the TGT to authentication system 510A (step Sk102). Authentication system 510A performs authorization authentication for the case and obtains authorization to issue a service ticket (step Sk103).

[0439] 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 sends the service ticket for company C to the authentication system 510A (step Sk105).

[0440] Next, the authentication system 510A sends a service ticket to the authentication system 510C of company C in order to obtain permission to send data from company C (step Sk106). The authentication system 510C receives the service ticket. The authentication system 510C sends permission to send data to the authentication system 510A (step Sk107).

[0441] Subsequently, the authentication system 510A transmits to the authentication system 510C the recruitment opportunities registered in the recruitment opportunity database 524 that are permitted to be disclosed to company C according to the disclosure permission list 521. This allows company A to allow applicants at company C to view its recruitment opportunities. Alternatively, 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 to determine the right to view the recruitment opportunities.

[0442] When Kerberos authentication is applied to matching system 1, company A can simplify the authentication process when sending a project to a company other than company C by using its acquired TGT. For example, if company A wants to send a project to company D, company A's authentication system 510A presents its acquired TGT and requests a service ticket for company D from TGS. If there are no problems with the TGT, TGS issues a service ticket for company D to authentication system 510A.

[0443] By utilizing the Kerberos authentication described above, a single sign-on (Single Sign-On) method can be implemented in matching system 1. As a result, for example, when sending data such as job postings from company A to other companies, there is no need for each company to authenticate separately. Here, companies A and C are shown as an example of multiple companies. However, the Kerberos authentication described above may also be applied as an authentication method between three or more companies.

[0444] According to the embodiment described above, the ordering company can provide project information to only a limited number of companies, thereby preventing the leakage of confidential information. The receiving company can receive project information from companies whose reliability is guaranteed by the matching system 1,1A, thus obtaining highly reliable project information.

[0445] According to this embodiment, recruiters can set companies to be kept confidential separately from the disclosure level (see Figure 13). In other words, in this embodiment, recruiter device 200 accepts an operation to input target groups (companies to be kept confidential) from which disclosure of business information is prohibited, and transmits information that can identify the received target group ("non-disclosure targets" from the "disclosed information") to the sharing server 100. The sharing server 100 prohibits the disclosure of business information to applicants belonging to the target group, even if the disclosure level is a level that allows the disclosure of business information to the target group (disclosure level) (S1442). Therefore, according to this embodiment, it is possible to individually set companies from which disclosure of recruitment information is to be restricted.

[0446] According to this embodiment, the manager of the company to which the employee belongs can confirm the details of the work that the employee has been contracted to do, thereby preventing the leakage of confidential information. Furthermore, according to this embodiment, the contracting company can keep track of the employee's main work hours and side work hours. As a result, the contracting company can manage the employee's health.

[0447] As described above, this embodiment provides a matching system 1,1A that functions as a crowdsourcing platform. In order to find more suitable personnel using crowdsourcing, it is desirable to broaden the scope of crowdsourcing rather than limiting it to a specific company or a small number of companies. In this case, it becomes necessary to consider the interests of the recruiter who is looking for someone to undertake the work and the applicant who is applying for that job. According to the matching system 1,1A of this embodiment, it is possible to select an appropriate applicant while taking into account the interests of the recruiter and the applicant.

[0448] The sharing server 100 and user device 500 are examples of compute devices that communicate with applicant devices and can access databases. The sharing server 100 and user device 500 register business information and disclosure information indicating the scope of disclosure of business information in databases 120 and 520. The sharing server 100 and user device 500 determine which business information registered in databases 120 and 520 is permitted to be disclosed to applicants based on the disclosure information, and provide (transmit) the business information permitted to be disclosed to applicants to applicant device 300. The sharing server 100 and user device 500 determine whether to permit disclosure to the first to third applicants according to the disclosure level (step S1452A).

[0449] The disclosure information has multiple disclosure levels, including "Same Company," "Community," and "Unrestricted." These multiple disclosure levels include Level 1 and Level 2. Level 1 (e.g., "Internal") corresponds to allowing the disclosure of business information to applicants belonging to Group 1 and prohibiting the disclosure of business information to applicants not belonging to Group 1 (see Figure 22). Level 2 (e.g., "Community") corresponds to allowing the disclosure of business information to applicants belonging to either Group 1 or community groups with which Group 1 has a community relationship, and prohibiting the disclosure of business information to applicants not belonging to either Group 1 or any community group (see Figure 22). Level 3 corresponds to allowing the disclosure of business information to applicants belonging to Group 1 and specific community groups different from those with which Group 1 has a community relationship, and prohibiting the disclosure of business information to applicants not belonging to either Group 1 or any specific community group (see modified example of Figure 22).

[0450] Multiple disclosure levels include a level (see Figure 22) that allows disclosure of business information to applicants regardless of the group to which the applicant belongs. Databases 120 and 520 contain attribute data (community IDs) that can identify community groups, and the sharing server 100 and user device 500 identify applicants who are permitted to receive business information based on the disclosure information and attribute data.

[0451] When the sharing server 100 and user device 500 receive input from a target group from which disclosure of business information is prohibited (the company ID of a company subject to non-disclosure), they prohibit the disclosure of business information to applicants belonging to that group, even if the disclosure level is at a level that allows disclosure of business information to the target group.

[0452] The sharing server 100 receives a request from the recruiter device 200 to search for information on multiple registered users (members) registered in the database 120 (step S21), and provides the search results based on the received request to the recruiter device (step S22). The recruiter device 200 receives an operation from the recruiter to select applicants who are recommended to apply from the search results (step S23), and sends the identification information of the selected applicants (member IDs of members targeted for the counter-offer) to the sharing server 100. The sharing server 100 sends information to the applicant device 300 of the selected applicants to encourage them to apply (step S24).

[0453] The sharing server 100 registers multiple profile information for each of the multiple registered users (members) in the database 120 (see Figure 35). The sharing server 100 accepts input from each of the multiple registered users to set the scope of the multiple profile information to be made public as search results (it accepts setting operations to allow publication for each type of profile information). The sharing server 100 accepts input of recruitment type information (recruitment type shown in Figure 41) that can identify whether the work for which contractors are being sought is a group work that can be awarded when multiple applicants apply together, or a work that can be awarded to a single applicant. The sharing server 100 registers the recruitment type information in the database 120 in association with the work information (step S1442).

[0454] The sharing server 100 registers application groups (member groups) consisting of multiple applicants in the database 120. The sharing server 100 accepts applications from application groups (determination unit 145A) regarding business information that is permitted to be disclosed to all applicants belonging to the application group.

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

[0456] (a-2) The system further comprises a second evaluator device operated by one or more evaluators belonging to a second group different from the first group, the second evaluator device receiving input of evaluations for contractors, transmitting the received evaluations to the compute device, the compute device registering second evaluation information based on the evaluations received from the second evaluator device in a database for each contractor, and when the compute device receives a viewing request in a second communication established by identification information that can identify that the person belongs to the second group, it transmits the second evaluation information to the sender that sent the viewing request in the second communication.

[0457] (a-3) The first group is made up of the first company, and the second group is made up of the second company, which is different from the first company.

[0458] (a-4) Group 1 consists of the first division of Company 1, and Group 2 consists of the second division of Company 1.

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

[0460] (a-6) The first group includes one or more evaluators belonging to the first division group and one or more evaluators belonging to a second division group different from the first division group, and the compute device calculates a first average value, which is the average of the evaluations for a given contractor, based on the evaluations for a given contractor received from multiple evaluators belonging to the first division group, and the compute device calculates a second average value, which is the average of the evaluations for a given contractor, based on the evaluations for a given contractor received from multiple evaluators belonging to the second division group, and the compute device calculates an average of the evaluations for a given contractor, based on the evaluations for a given contractor received from multiple evaluators belonging to the first group Based on this, the compute device calculates a third average value, which is the average of the evaluations for a given contractor. When the compute device receives a viewing request in a third communication established with identification information that identifies the person as belonging to the first division group, it transmits the first and third average values ​​as the first evaluation information for the given contractor to the sender who sent the viewing request in the third communication. When the compute device receives a viewing request in a fourth communication established with identification information that identifies the person as belonging to the second division group, it transmits the second and third average values ​​as the first evaluation information for the given contractor to the sender who sent the viewing request in the fourth communication.

[0461] (a-7) The database contains a list of contractors. When the first evaluator device receives an operation to search the list, it sends a search request to the compute device. When the compute device receives the search request, it sends the search results to the sender who sent the viewing request in the first communication, excluding contractors from the list whose evaluation level, as identified by the first evaluation information, does not meet the criteria.

[0462] (a-8) The database contains multiple pieces of business information along with disclosure information indicating the scope of disclosure to applicants. The evaluation system further includes an applicant device operated by applicants belonging to the second group. The compute device determines, based on the disclosure information, which 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 permitted to be disclosed to applicants belonging to the second group to the applicant device.

[0463] (a-9) An evaluator device operated by one or more evaluators belonging to the first group, comprising: an interface for receiving input of evaluations for contractors who have applied for a job; a reception unit for receiving viewing requests; a display; and a processor for transmitting the evaluations received by the interface and the viewing requests received by the reception unit to a compute device that can access a database, wherein, when a viewing request is received, the processor displays the evaluations of one or more evaluators belonging to the first group on the display.

[0464] (a-10) A method for evaluating contractors who have applied for work, 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 in a database based on the evaluation received from the first evaluator device; and, if a viewing request is received in a first communication established by identification information that can identify that the person belongs to the first group, transmitting the first evaluation information to the sender that sent the viewing request in the first communication.

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

[0466] (b-2) The system further comprises a second evaluator device operated by one or more evaluators belonging to a second group different from the first group, the second evaluator device receiving input of evaluations for recruiters and transmitting the received evaluations to the compute device, the compute device registering second evaluation information based on the evaluations received from the second evaluator device in a database for each recruiter, and the compute device transmitting the second evaluation information to the sender that sent the access request in the second communication when it receives a viewing request in a second communication established by identification information that can identify that the person belongs to the second group.

[0467] (b-3) The first group is made up of the first company, and the second group is made up of the second company, which is different from the first company.

[0468] (b-4) Group 1 consists of the first division of Company 1, and Group 2 consists of the second division of Company 1.

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

[0470] (b-6) The first group includes one or more evaluators belonging to the first division group and one or more evaluators belonging to a second division group different from the first division group, and the compute device calculates a first average value, which is the average of the evaluations for a given recruiter, based on the evaluations for a given recruiter received from multiple evaluators belonging to the first division group, and the compute device calculates a second average value, which is the average of the evaluations for a given recruiter, based on the evaluations for a given recruiter received from multiple evaluators belonging to the second division group, and the compute device calculates an average of the evaluations for a given recruiter, based on the evaluations for a given recruiter received from multiple evaluators belonging to the first group Based on this, the compute device calculates a third average value, which is the average of the evaluations for a given recruiter. When the compute device receives a viewing request in a third communication established with identification information that identifies the person as belonging to the first division group, it transmits the first and third average values ​​as the first evaluation information for the given recruiter to the sender that sent the viewing request in the third communication. When the compute device receives a viewing request in a fourth communication established with identification information that identifies the person as belonging to the second division group, it transmits the second and third average values ​​as the first evaluation information for the given recruiter to the sender that sent the viewing request in the fourth communication.

[0471] (b-7) The database contains a list of recruiters. When the first evaluator device receives a request to search the list, it sends a search request to the compute device. When the compute device receives the search request, it sends the search results to the sender who sent the viewing request in the first communication, excluding recruiters from the list whose evaluation level, as identified by the first evaluation information, does not meet the criteria.

[0472] (b-8) The database contains multiple pieces of business information along with disclosure information indicating the scope of disclosure to applicants. The evaluation system further includes an applicant device operated by applicants belonging to the second group. The compute device determines, based on the disclosure information, which 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 permitted to be disclosed to applicants belonging to the second group to the applicant device.

[0473] (b-9) An evaluator device operated by one or more evaluators belonging to the first group, comprising: an interface for receiving input of evaluations for recruiters who recruit applicants for work; a reception unit for receiving viewing requests; a display; and a processor for transmitting evaluations received by the interface and viewing requests received by the reception unit to a compute device that can access a database, wherein, when a viewing request is received, the processor displays evaluations by one or more evaluators belonging to the first group on the display.

[0474] (b-10) A method for evaluating recruiters who recruit applicants for work, 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 in a database based on the evaluation received from the first evaluator device; and, if a viewing request is received in a first communication established by identification information that can identify that the person belongs to the first group, transmitting the first evaluation information to the sender that sent the viewing request in the first communication.

[0475] (c-1) A matching system for matching a recruiter who is recruiting contractors for a project with applicants, comprising a first applicant device operated by the first applicant and a compute device that communicates with the first applicant device and can access a database, wherein the compute device registers project information for recruiting contractors and disclosure information indicating the scope of disclosure of the project information in the database, the compute device determines which project information registered in the database is permitted to be disclosed to the first applicant based on the disclosure information, the project information includes detailed information about the content of the project, and the compute device displays the project information permitted to be disclosed to the first applicant and terms included in the detailed information to the first applicant device.

[0476] (c-2) The terms included in the detailed information are in-house terms that are commonly used within the group to which the recruiter belongs.

[0477] (c-3) The compute device registers in-house terminology and the meanings of those terms in a database.

[0478] (c-4) The compute device registers in-house terminology in a database, categorized by the group to which the recruiter belongs.

[0479] (c-5) When the compute device detects an operation by the first applicant on an in-house term in the first applicant's device, it transmits information that can identify the meaning of the in-house term registered in the database to the first applicant's device.

[0480] (c-6) The compute 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 and their meanings associated with each term.

[0481] (c-7) A compute device included in a matching system for matching a recruiter who is recruiting contractors for a project with applicants, comprising a communication interface that communicates with a first applicant device operated by the first applicant, and a processor that accesses a database, wherein the processor registers project information for recruiting contractors and disclosure information indicating the scope of disclosure of the project information in the database, the processor determines which project information registered in the database is permitted to be disclosed to the first applicant based on the disclosure information, the project information includes detailed information about the content of the project, and the processor displays to the first applicant device the project information permitted to be disclosed to the first applicant and the meaning of terms included in the detailed information.

[0482] (c-8) A method for matching a recruiter who is recruiting contractors for a service with applicants, comprising the steps of: communicating with a first applicant device operated by the first applicant; registering in a database information for a service that is recruiting contractors and disclosure information indicating the scope of disclosure of the service information; and determining, based on the disclosure information, which of the service information registered in the database is permitted to be disclosed to the first applicant, wherein the service information includes detailed information relating to the content of the service, and the method further comprises the step of displaying to the first applicant the service information that is permitted to be disclosed to the first applicant and the meaning of terms contained in the detailed information.

[0483] (d-1) The user device includes a second applicant device operated by a second applicant different from the first applicant, and the compute device determines, based on the disclosure information, which of the business cases registered in the database are permitted to be disclosed to the second applicant, and provides the business cases permitted to be disclosed to the second applicant to the second applicant device.

[0484] (d-2) The user equipment includes a third applicant equipment operated by a third applicant distinct from the first and second applicants, and the disclosure information has multiple disclosure levels, and the compute equipment determines whether to allow disclosure to the first to third applicants separately, depending on the disclosure level.

[0485] (d-3) The first applicant belongs to Group 1, and the second applicant belongs to Group 2, which is different from Group 1. Multiple disclosure levels include Level 1 and Level 2. Level 1 corresponds to allowing disclosure of the job opportunity to the first applicant and prohibiting disclosure of the job opportunity to applicants who do not belong to Group 1. Level 2 corresponds to allowing disclosure of the job opportunity to applicants who belong to either Group 1 or a community group with which a community relationship has been formed with Group 1, and prohibiting disclosure of the job opportunity to applicants who do not belong to either Group 1 or a community group.

[0486] (d-4) The first applicant belongs to Group 1, the second applicant belongs to Group 2 which is different from Group 1, and there are multiple levels of disclosure, including Level 1, Level 2, and Level 3, with Level 1 allowing disclosure of the job opportunity to the first applicant and prohibiting disclosure of the job opportunity to applicants who do not belong to Group 1, Level 2 allowing disclosure of the job opportunity to applicants who belong to either Group 1 or a community group with which Group 1 has a community relationship, and Level 3 allowing disclosure of the job opportunity to applicants who belong to either Group 1 or a specific community group different from the Level 2 community group with which Group 1 has a community relationship, and prohibiting disclosure of the job opportunity to applicants who do not belong to either Group 1 or the specific community group.

[0487] (d-5) Multiple disclosure levels include a level of disclosure that allows for the disclosure of job opportunities to applicants regardless of the group to which the applicant belongs.

[0488] (d-6) The database contains attribute data that can identify community groups, and the compute device identifies applicants who are permitted to disclose job opportunities based on the disclosed information and attribute data.

[0489] (d-7) If the compute device receives input from a group that is prohibited from disclosing business opportunities, it will prohibit the disclosure of business opportunities to applicants belonging to that group, even if the disclosure level is at a level that allows disclosure of business opportunities to the group.

[0490] (d-8) The compute device receives a request from the recruiter device to search for information on multiple registrants registered in the database, provides the recruiter device with the search results based on the received request, the recruiter device receives an operation to select applicant recommenders from the search results who are recommended to apply, transmits the identification information of the selected applicant recommenders to the compute device, and the compute device transmits information to the applicant device of the selected applicant recommenders to encourage them to apply.

[0491] (d-9) The compute device registers multiple profile information for each of the multiple registrants into the database, and the compute device accepts input from each of the multiple registrants to set the scope of the multiple profile information to be made public as search results.

[0492] (d-10) When the compute device receives input of recruitment type information that can identify whether the work for which a contractor is being sought is a group project that can be awarded when multiple applicants apply together, or a project that can be awarded to a single applicant, it registers the recruitment type information in the database, associating it with the project.

[0493] (d-11) The compute device registers application groups consisting of multiple applicants in its database, and the compute device can accept applications from application groups for business projects that are permitted to be disclosed to all applicants belonging to the application group.

[0494] [Pattern] The following are the aspects of this disclosure.

[0495] (Paragraph 1) The matching system described in Paragraph 1 is a matching system for matching business cases, comprising a user device operated by a user and a compute device configured to access a database in which business cases are registered and to disclose business cases to the user, wherein the user device includes a first user device operated by a first user belonging to a first group and a second user device operated by a second user, the compute device sets the scope of disclosure of business cases provided by the second user based on disclosure information indicating the scope of disclosure of business cases, the first user device transmits restriction information to the compute device that restricts the disclosure of business cases to the first group based on the operation of the first user, and the compute device restricts the disclosure of business cases provided by the second user to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the disclosure information.

[0496] (Paragraph 2) The matching system described in Paragraph 2, in the matching system described in Paragraph 1, includes one of the following as restriction information: user specification information for specifying restricted users, industry specification information for specifying restricted industries, and company specification information for specifying restricted companies.

[0497] (Clause 3) In the matching system described in paragraph 3, the second user belongs to the second group, and the user designation information includes information that designates the second group.

[0498] (Article 4) The matching system described in Article 4 is a matching system described in any one of Articles 1 to 3, wherein the business case provided by the second user includes a first case and a second case, and the first user device is configured to selectively transmit restriction information for the first case and restriction information for the second case to the compute device based on the operation of the first user.

[0499] (Article 5) In the matching system described in Article 5, the first user device transmits restriction information to the compute device if the first user is authorized to set restriction information.

[0500] (Paragraph 6) In the matching system described in Paragraph 6, the second user device transmits the disclosed information to the compute device in response to the operation of the second user.

[0501] (Clause 7) The matching system described in paragraph 7 is a matching system described in any one of paragraphs 1 to 6, wherein the user device includes a first applicant device operated by the first applicant, and the compute device determines which business cases registered in the database are permitted to be disclosed to the first applicant based on the disclosure information and the restriction information, and provides the business cases permitted to be disclosed to the first applicant to the first applicant device.

[0502] (Clause 8) The matching system described in paragraph 8 is the matching system described in any one of paragraphs 1 to 7, wherein the user device includes a recruiter device operated by the recruiter, and the recruiter device transmits job postings and disclosure information to the compute device.

[0503] (Paragraph 9) The matching system described in Paragraph 9 is the matching system described in any one of Paragraphs 1 to 7, wherein the user device includes a recruiter device operated by the recruiter, and the compute device includes a recruiter device.

[0504] (Clause 10) The user device described in paragraph 10 is a user device that communicates with a compute device that matches business cases, the compute device is configured to access a database in which business cases are registered and to disclose business cases to the user, the compute device sets the scope of disclosure of business cases based on disclosure information indicating the scope of disclosure of business cases and restriction information, the user device comprises a receiving unit that receives user operations to input restriction information and a transmitting unit that transmits restriction information to the compute device when the user operation is received by the receiving unit, the restriction information is information that restricts the disclosure of business cases to the first group to which the first user belongs, regardless of the scope of disclosure based on the disclosure information.

[0505] (Clause 11) The compute device described in paragraph 11 is a compute device that communicates with a user device and matches business cases, and includes a setting unit that accesses a database in which business cases are registered and sets business cases to be disclosed to the first group to which the first user belongs based on disclosure information indicating the scope of disclosure of business cases, a receiving unit that receives restriction information from the user device that restricts the disclosure of business cases to the first group, and a restriction unit that, upon receiving restriction information, restricts the disclosure of business cases to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the disclosure information.

[0506] (Paragraph 12) The method described in Paragraph 12 is a method for matching business cases, comprising the steps of: accessing a database in which business cases are registered and setting business cases to be disclosed to the first group to which the first user belongs, based on disclosure information indicating the scope of disclosure of business cases; receiving restriction information from a user device that restricts the disclosure of business cases to the first group; and, upon receiving restriction information, restricting the disclosure of business cases to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the disclosure information.

[0507] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the claims rather than by the description of the embodiments above, and all modifications within the meaning and scope of the claims are intended to be included. [Explanation of Symbols]

[0508] 1 Matching system, 50 Internet, 100 Sharing server, 101 Processor, 102 Memory, 103,503 Storage, 104 Communication interface, 120,520 Database (DB), 121 Corporate database (Corporate DB), 122,122A Member database (Member DB), 123 Community database (Community DB), 124,124A,524 Job posting database (Job Posting DB), 125 Side job database (Side job DB), 126 Evaluation input database (Evaluation input DB), 126A Recruiter evaluation department, 126B Applicant evaluation department, 127 Evaluation summary database (Evaluation summary DB), 127A Recruiter evaluation summary department, 127B Applicant evaluation summary department, 128 Member group database (Member group DB), 129 Profile database (Profile DB), 137 Internal terminology database (Internal terminology DB), 140 Community Registration Section, 141 Company Registration Section, 142 Member Registration Section, 143 Member Search Section, 144 Project Registration Section, 145 Project Extraction Section, 145A Member Group Information Acquisition Section, 146 Application Section, 147 Approval Section, 148 Notification Section, 149 Performance Reception Section, 150 Performance Output Section, 151 Evaluation Reception Section, 152 Evaluation Output Section, 161 Reverse Offer Request Section, 162 Reverse Offer Approval Request Section, 163 Reverse Offer Request Acceptance Notification Section, 200, 200A, 200B, 200C Recruiter Device, 201 Processor, 202 Memory, 203 Communication Interface, 204 Input / Output Interface, 205 Display, 206 Operation Section, 206A Keyboard, 206B Mouse, 300, 300A, 300B, 300C Applicant Device, 301 Processor, 302 Memory, 303 Communication interface, 304 Input / Output interface, 305 Display, 306 Control panel, 306A Keyboard, 306B Mouse, 307A~307C Tabs, 308 Cursor, 401,402 Tables, 500 User device, 521 Disclosure permission list, Screens 551,552, 1271,1272 Data sets.

Claims

1. It is a matching system that matches business projects, A user device operated by a user, The system includes a compute device configured to access a database containing the business cases and to disclose the business cases to users, The user device includes a first user device operated by a first user belonging to the first group, and a second user device operated by a second user. The compute device sets the scope of disclosure of the business case provided by the second user based on the disclosure information indicating the scope of disclosure of the business case, The first user device transmits restriction information to the compute device that restricts the disclosure of business cases to the first group based on the operation of the first user. Regardless of the scope of disclosure set based on the disclosed information, the compute device restricts the disclosure of business cases provided by the second user to the first group in accordance with the restriction information. The aforementioned restriction information is a matching system that includes one of the following: user specification information for specifying the restricted user, industry specification information for specifying the restricted industry, and company specification information for specifying the restricted company.

2. The aforementioned second user belongs to the second group, The matching system according to claim 1, wherein the user-specified information includes information specifying the second group.

3. The business project provided by the second user includes the first project and the second project, The matching system according to claim 1, wherein the first user device is configured to selectively transmit the restriction information relating to the first case and the restriction information relating to the second case to the compute device based on the operation of the first user.

4. The matching system according to claim 1, wherein the first user device transmits the restriction information to the compute device when the first user is a person authorized to set the restriction information.

5. The matching system according to claim 1, wherein the second user device transmits the disclosed information to the compute device in response to the operation of the second user.

6. The user device includes a first applicant device operated by the first applicant, The matching system according to claim 1, wherein the compute device determines, based on the disclosure information and the restriction information, which of the business cases registered in the database are permitted to be disclosed to the first applicant, and provides the business cases permitted to be disclosed to the first applicant to the first applicant device.

7. The user device includes a recruiter device operated by the recruiter, The matching system according to claim 1, wherein the recruiting device transmits the job postings and the disclosure information to the compute device.

8. The user device includes a recruiter device operated by the recruiter, The matching system according to claim 1, wherein the compute device includes the recruiter device.

9. A user device that communicates with a compute device that matches business projects, The compute device is configured to access the database in which the business cases are registered and to disclose the business cases to the user. The compute device sets the scope of disclosure of the business case based on the disclosure information indicating the scope of disclosure of the business case and the restriction information, The User device is A reception unit that receives user input for the aforementioned restriction information, The system includes a transmission unit that transmits the restriction information to the compute device when the user operation is received by the reception unit, The aforementioned restriction information is information that restricts the disclosure of the business case to the first group to which the first user belongs, regardless of the scope of disclosure based on the aforementioned disclosure information. The aforementioned restriction information includes one of the following: user-specific information for specifying the restricted user, industry-specific information for specifying the restricted industry, and company-specific information for specifying the restricted company.

10. A compute device that communicates with user devices and matches them with business cases, A setting unit accesses the database in which the aforementioned business cases are registered and sets the business cases to be disclosed to the first group to which the first user belongs, based on the disclosure information indicating the scope of disclosure of the aforementioned business cases. A receiving unit that receives restrictive information from the user device that restricts the disclosure of business cases to the first group, The system includes a restriction unit that, upon receiving the aforementioned restriction information, restricts the disclosure of the business case to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the aforementioned disclosure information. The aforementioned restriction information includes one of the following: user-specific information for specifying the restricted user, industry-specific information for specifying the restricted industry, and company-specific information for specifying the restricted company.

11. A method for matching business projects, The steps include: accessing the database in which the aforementioned business cases are registered, and setting the business cases to be disclosed to the first group to which the first user belongs, based on the disclosure information indicating the scope of disclosure of the aforementioned business cases; The steps include receiving restrictive information from the user device that restricts the disclosure of business cases to the aforementioned first group, Upon receiving the aforementioned restriction information, the system includes the step of restricting the disclosure of the business case to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the aforementioned disclosure information. The method includes, for the purpose of specifying the restricted user, for specifying the restricted industry, and for specifying the restricted company.

12. A matching system for matching business projects, A user device operated by a user, The system includes a compute device configured to access a database containing the business cases and to disclose the business cases to users, The user device includes a first user device operated by a first user belonging to the first group, and a second user device operated by a second user. The compute device sets the scope of disclosure of the business case provided by the second user based on the disclosure information indicating the scope of disclosure of the business case, The first user device transmits restriction information to the compute device that restricts the disclosure of business cases to the first group based on the operation of the first user. Regardless of the scope of disclosure set based on the disclosed information, the compute device restricts the disclosure of business cases provided by the second user to the first group in accordance with the restriction information. The business project provided by the second user includes the first project and the second project, A matching system configured such that the first user device selectively transmits the restriction information for the first case and the restriction information for the second case to the compute device based on the operation of the first user.

13. A method for matching business projects, A user device operated by a user, This includes a number of steps performed by a compute device configured to access a database in which the aforementioned business cases are registered and to disclose the aforementioned business cases to users, The user device includes a first user device operated by a first user belonging to the first group, and a second user device operated by a second user. The aforementioned steps are: The compute device sets the scope of disclosure of the business case provided by the second user based on the disclosure information indicating the scope of disclosure of the business case, The first user device transmits to the compute device, based on the operation of the first user, restriction information that restricts the disclosure of business cases to the first group, The steps include: the compute device restricting the disclosure of business cases provided by the second user to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the disclosure information; The business project provided by the second user includes the first project and the second project, The method further includes the step of the first user device selectively transmitting the restriction information relating to the first case and the restriction information relating to the second case to the compute device based on the operation of the first user.

14. A matching system for matching business projects, A user device operated by a user, The system includes a compute device configured to access a database containing the business cases and to disclose the business cases to users, The user device includes a first user device operated by a first user belonging to the first group, and a second user device operated by a second user. The compute device sets the scope of disclosure of the business case provided by the second user based on the disclosure information indicating the scope of disclosure of the business case, The first user device transmits restriction information to the compute device that restricts the disclosure of business cases to the first group based on the operation of the first user. Regardless of the scope of disclosure set based on the disclosed information, the compute device restricts the disclosure of business cases provided by the second user to the first group in accordance with the restriction information. The user device includes a first applicant device operated by the first applicant, The compute device is a matching system that determines, based on the disclosure information and the restriction information, which of the business cases registered in the database are permitted to be disclosed to the first applicant, and provides the business cases permitted to be disclosed to the first applicant to the first applicant device.

15. A compute device that communicates with a user device and matches business cases, A setting unit accesses the database in which the aforementioned business cases are registered and sets the business cases to be disclosed to the first group to which the first user belongs, based on the disclosure information indicating the scope of disclosure of the aforementioned business cases. A receiving unit that receives restrictive information from the user device that restricts the disclosure of business cases to the first group, The system includes a restriction unit that, upon receiving the aforementioned restriction information, restricts the disclosure of the business case to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the aforementioned disclosure information. The user device includes a first applicant device operated by the first applicant, The compute device determines, based on the disclosure information and the restriction information, which of the business cases registered in the database are permitted to be disclosed to the first applicant, and provides the business cases permitted to be disclosed to the first applicant to the first applicant device.

16. A method for matching business projects, The steps include: accessing the database in which the aforementioned business cases are registered, and setting the business cases to be disclosed to the first group to which the first user belongs, based on the disclosure information indicating the scope of disclosure of the aforementioned business cases; The steps include receiving restrictive information from the user device that restricts the disclosure of business cases to the aforementioned first group, Upon receiving the aforementioned restriction information, the system includes the step of restricting the disclosure of the business case to the first group in accordance with the restriction information, regardless of the scope of disclosure set based on the aforementioned disclosure information. The user device includes a first applicant device operated by the first applicant, A method comprising the steps of determining, based on the disclosure information and the restriction information, which business cases registered in the database are permitted to be disclosed to the first applicant, and providing the business cases permitted to be disclosed to the first applicant to the first applicant device.

Images