Matching system, user device, computing device, and method

Abstract

A matching system (1) for matching business cases is provided with: a user device (500) operated by a user; and a computing device (100) configured to access a database in which business cases are registered and to publish the business cases to users, the user device (500) including 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 computing device (100) sets the publication range of the business case provided by the second user on the basis of publication information indicating the publication range of the business case, and the first user device transmits, to the computing device (100), restriction information that restricts the publication of the business case to the first group on the basis of an operation by the first user, and transmits, to the computing device (100), restriction information that restricts the publication of the business case to the second group. The computing device (100) restricts the disclosure of the business case provided by the second user to the first group in accordance with the restriction information regardless of the disclosure range set on the basis of the disclosure information.

Description

Technical Field

[0001] This disclosure relates to a matching system, user device, computing device, and method for matching business cases. Background Technology

[0002] Crowdsourcing has been flexibly utilized in businesses and other organizations in the past. Generally speaking, crowdsourcing refers to the process of soliciting contributions from an unspecified number of people to obtain needed services, ideas, or content. In crowdsourcing, it is necessary to identify individuals with the most suitable skills for the required business needs.

[0003] Patent document 1 describes the following method: comparing whether information related to the talent required for the development project is consistent with the information of the company's constituent personnel, and extracting the constituent personnel who meet the required talent from the entire organization of the company as the search results.

[0004] Existing technical documents

[0005] Patent documents

[0006] Patent Document 1: Japanese Patent Application Publication No. 2003-44642 Summary of the Invention

[0007] The problem the invention aims to solve

[0008] The crowdsourcing described in Patent Document 1 is implemented within a group of enterprises. However, to find more suitable talent, it is desirable to further expand the scope of crowdsourcing. In this case, the interests of users in matching business cases need to be considered. For example, a mechanism needs to be set in the matching system that allows the recruiter to control the disclosure of business cases, so that business cases related to the matching are not disclosed to competitors. However, simply setting such a mechanism in the matching system is sometimes insufficient to prevent the leakage of know-how to competitors.

[0009] This disclosure was made to address the aforementioned problems, and its purpose is to limit the scope of disclosure of business cases by taking into account the interests of users when matching business cases.

[0010] Solution for solving the problem

[0011] The matching system disclosed in the first aspect is used to match business cases. The matching system includes: a user device operated by a user; and a computing device configured to access a database containing registered business cases and disclose business cases to the user. 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 computing device sets the disclosure scope of business cases provided by the second user based on disclosure information indicating the disclosure scope of the business cases. The first user device sends restriction information to the computing device based on the operation of the first user, restricting the disclosure of business cases to the first group. Regardless of the disclosure scope set based on the disclosure information, the computing device restricts the disclosure of business cases provided by the second user to the first group according to the restriction information.

[0012] The second aspect of this disclosure relates to a user device communicating with a computing device that matches business cases. The computing device is configured to access a database containing registered business cases and disclose the business cases to a user. The computing device sets the scope of disclosure of the business cases based on disclosure information and restriction information indicating the scope of disclosure of the business cases. The user device includes: a receiving unit that receives user operations that input restriction information; and a sending unit that, when the receiving unit receives the user operation, sends the restriction information to the computing device. The restriction information restricts the disclosure of the business case information to a first group to which the first user belongs, regardless of the scope of disclosure based on the disclosure information.

[0013] The computing device according to the third aspect of this disclosure is a computing device for matching service cases that communicates with a user device, and includes: a setting unit that accesses a database in which service cases are registered and sets service cases to be disclosed to a first group to which a first user belongs based on disclosure information indicating the scope of disclosure of the service cases; a receiving unit that receives restriction information from the user device that restricts the disclosure of service cases to the first group; and a restriction unit that, upon receiving the restriction information, restricts the disclosure of service cases to the first group based on the restriction information, regardless of the scope of disclosure set based on the disclosure information.

[0014] The fourth aspect of this disclosure relates to a method for matching business cases, comprising the following steps: accessing a database of registered business cases; setting business cases to be disclosed to a first group to which a first user belongs based on public information indicating the scope of disclosure of the business cases; receiving restriction information from a user device restricting 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 based on the restriction information, regardless of the scope of disclosure set based on the public information.

[0015] The effects of the invention

[0016] According to this disclosure, the scope of disclosure of business cases can be limited by taking into account the interests of users when matching business cases. Attached Figure Description

[0017] Figure 1 This is a block diagram showing an overview of the matching system.

[0018] Figure 2 This is a block diagram showing the structure of the shared server, the recruiter device, and the applicant device.

[0019] Figure 3 This is a diagram illustrating an example of a corporate database.

[0020] Figure 4 This is a diagram illustrating an example of a member database.

[0021] Figure 5 This is a diagram illustrating an example of a community database.

[0022] Figure 6 This is a diagram illustrating an example of a recruitment case database.

[0023] Figure 7 This is a diagram illustrating an example of a side hustle database.

[0024] Figure 8 This is a diagram illustrating an example of evaluating an input database.

[0025] Figure 9 This is a diagram illustrating an example of an evaluation summary database.

[0026] Figure 10 This diagram illustrates the functions of the shared server, recruiter device, and applicant device.

[0027] Figure 11 This diagram illustrates the functions of the shared server, recruiter device, and applicant device.

[0028] Figure 12 This diagram illustrates the functions of the shared server, recruiter device, and applicant device.

[0029] Figure 13 This diagram is used to further illustrate the function of the applicant's device.

[0030] Figure 14 This is a diagram illustrating the process of registering recruitment cases into the recruitment case database.

[0031] Figure 15 This is a diagram used to illustrate the process of retrieving recruitment cases from a database.

[0032] Figure 16This is a diagram illustrating the process of recording the reservations and achievements of side jobs in a database.

[0033] Figure 17 This is a diagram illustrating the process of registering applicants' evaluations in a database.

[0034] Figure 18 This is a diagram illustrating the process of registering evaluations of recruiters into a database.

[0035] Figure 19 This is a diagram illustrating the process of displaying applicant reviews and member search results on a screen.

[0036] Figure 20 This is a diagram illustrating the process of displaying evaluations of recruiters and search results for members on a screen.

[0037] Figure 21 This is a diagram used to illustrate the browsable scope of the evaluation summary database.

[0038] Figure 22 This is a diagram illustrating an example of setting the scope of disclosure based on the level of disclosure.

[0039] Figure 23 This is a screenshot displayed on the manager's (the applicant's supervisor) device when the manager checks the subordinate's side job status.

[0040] Figure 24 This is an image showing the screen displayed on the applicant's device when the administrator changes the browsing restriction settings.

[0041] Figure 25 This is a timing diagram showing the relationship between the setting of constraint information.

[0042] Figure 26 This is a diagram showing details of cases included in the recruitment case database.

[0043] Figure 27 This is a diagram illustrating an example of a profile database.

[0044] Figure 28 This is a diagram illustrating an example of a company's internal terminology database.

[0045] Figure 29 This is a flowchart illustrating the processing procedures related to the indexing function of the matching system.

[0046] Figure 30 This is a flowchart illustrating the processing procedures of the company's internal terminology registration department.

[0047] Figure 31 This is a flowchart illustrating the processing procedure of the case registration department.

[0048] Figure 32 This is a flowchart illustrating the process of displaying the meaning of company terminology on a screen based on the applicant's actions.

[0049] Figure 33 This is a flowchart relating to the processing of restriction information performed by the shared server as a variation of Example 1.

[0050] Figure 34 This is a diagram used to illustrate the functions of the shared server, recruiter device, and applicant device in relation to Variation 2.

[0051] Figure 35 This is a diagram illustrating an example of a member database related to Variation 2.

[0052] Figure 36 This is a flowchart illustrating the process of reverse offer member retrieval related to Variation Example 2.

[0053] Figure 37 This is a block diagram showing the structure of the shared server, recruiter device, and applicant device related to Variation 3.

[0054] Figure 38 This is a diagram illustrating an example of a member group database related to Variation 3.

[0055] Figure 39 This is a diagram illustrating an example of a recruitment case database related to Variation 3.

[0056] Figure 40 This is a diagram used to illustrate the functions of the shared server, recruiter device, and applicant device in relation to Variation 3.

[0057] Figure 41 This is a diagram illustrating the process of registering recruitment cases into the recruitment case database in relation to Variation 3.

[0058] Figure 42 This is a diagram showing the structure of the matching system related to variant example 4.

[0059] Figure 43 This is a diagram illustrating an example (Variation 5) of applying Kerberos authentication to a matching system. Detailed Implementation

[0060] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings. Furthermore, the same or equivalent parts in the drawings will be labeled with the same reference numerals, and their descriptions will not be repeated.

[0061] [Background for proposing Matching System 1]

[0062] Figure 1This is a block diagram showing an outline of the matching system 1 according to this embodiment. First, the background of proposing the matching system 1 in this embodiment will be explained.

[0063] Matching systems, for example, are flexibly used in inter-enterprise crowdsourcing. Crowdsourcing is generally the process of soliciting contributions from an unspecified number of people to obtain the services, ideas, or content they need.

[0064] Many companies are developing side businesses to effectively utilize human resources. By leveraging crowdsourcing among companies, they can make the most of their employees' abilities.

[0065] However, when general crowdsourcing methods are applied directly between enterprises, the following problems may arise.

[0066] [Possibility of leaked confidential information]

[0067] Traditional crowdsourcing methods don't consider the relationship between the company providing the services and the company handling them. Therefore, crowdsourcing carries both business and personal risks. For example, there's a possibility that confidential information could be leaked to a competitor through an employee's side job. Furthermore, in traditional crowdsourcing methods, managers cannot verify whether employees are handling cases involving competitor companies as side jobs.

[0068] [Possibility of overwork]

[0069] When companies allow employees to take on side jobs, employees' working hours may become excessively long. To mitigate the risk of overwork, it's also worth considering having companies set caps on overtime hours that include both primary and side jobs. However, as long as employees are free to take on side jobs, companies find it difficult to manage their side job hours. As a result, employees may become overworked.

[0070] [The possibility that the results of a side hustle are not being properly evaluated]

[0071] Previously, there were crowdsourcing systems where publishers were asked to evaluate job providers. In crowdsourcing systems where appropriate evaluations from publishers were shared, those recruiting job providers could refer to these evaluations to select the most capable individuals from among many potential clients.

[0072] However, a publisher of a particular business might be overly considerate of other businesses' service providers, entering higher ratings than intended into the system. Additionally, a publisher might avoid giving lower ratings to other businesses' service providers due to concerns about potential deterioration in inter-company relationships. Furthermore, the publisher might not perceive any benefit from conducting evaluations, thus entering ratings far removed from their intended purpose. When these possibilities are taken into account, the reliability of the system's evaluations may decrease. In such cases, even if service provider ratings are shared, the business publisher cannot flexibly utilize these ratings as reference data when selecting service providers.

[0073] [Potential inability to obtain accurate information about the recruiter]

[0074] In crowdsourcing systems like the one described above, applicants considering jobs are advised to choose those that meet their criteria, such as job description and compensation. However, some recruiters may frequently issue additional requests or change the job description outside the scope of the contract. As an applicant, one would want to avoid applying for jobs recruited by such recruiters. Conversely, there are also recruiters who will not cause problems until the job is completed. As an applicant, one would prefer to apply for jobs recruited by such recruiters. Therefore, it is desirable for crowdsourcing systems to widely share evaluations not only of applicants (job seekers) but also of recruiters (job posters).

[0075] With appropriate evaluations of recruiters shared in the crowdsourcing system, those applying for jobs can refer to these evaluations and consider the recruiter's past transaction history to select suitable jobs from a large pool of available opportunities.

[0076] However, building an evaluation system that assesses recruiters may present the same problems as building one that assesses job seekers. Specifically, a job seeker (applicant) might input a higher rating than intended, perhaps out of consideration for other companies' advertisers (recruiters) being evaluated. Alternatively, a job seeker might avoid giving lower ratings to other companies' advertisers (recruiters) due to concerns about potential deterioration in inter-company relationships. Furthermore, job seekers might not perceive any benefit from evaluations, thus inputting ratings far removed from their intended value. Considering these possibilities, the reliability of the system's evaluations may decrease. In such cases, even if recruiter evaluations are shared, job seekers cannot flexibly utilize these evaluations as reference data when selecting recruiters.

[0077] [Regarding the special considerations of setting the matching subject to an enterprise]

[0078] Generally speaking, in order to match talent and business across enterprises, a close relationship, such as one of trust, is required between the enterprises matching the talent and business. Therefore, matching talent and business across enterprises without capital ties is very difficult. In addition, large enterprises such as listed companies are prone to competition with other companies from the perspective of diversified operations, and may even engage in mergers and acquisitions, thus creating special situations where talent and business cannot be matched with many enterprises.

[0079] [The Potential for Company Language to Hinder Communication]

[0080] Sometimes, companies develop their own unique internal terminology. While employees within the company that uses this terminology may understand it, those outside the company may not. Alternatively, the terminology might be understood as having a specific meaning among those who use it, but be interpreted differently by those outside the company.

[0081] Recruitment guidelines may use company terminology. If the recruiter's company and the applicant's company are different, the applicant may not correctly understand the meaning of the company terminology used in the recruitment guidelines. The applicant may apply for the recruitment job without properly understanding the meaning of the company terminology used in the recruitment guidelines. As a result, business disputes may arise.

[0082] In negotiations between recruiters and applicants, company terminology may be used. If the recruiter and applicant belong to different companies, the applicant may not fully understand the meaning of the company terminology used by the recruiter. Similarly, the recruiter may not fully understand the meaning of the company terminology used by the applicant.

[0083] If one party uses unfamiliar company terminology, the other party can usually understand its meaning by asking the speaker. However, if the recruiter and applicant have different understandings of the terminology, negotiations will continue without correcting this cognitive bias. This can potentially lead to business disputes.

[0084] Regarding terms similar to those used within companies, there's a possibility that these terms, with their unique meanings, may also be prevalent not only in corporations but also in non-profit organizations. Whether for-profit or non-profit, an organization is typically divided into departments, sections, and other units, potentially leading to the proliferation of terms with distinct meanings within each unit. Alternatively, such terms may also be prevalent within communities formed by the aggregation of multiple corporations or other groups. Therefore, when recruiters and applicants belong to different groups, units, or communities, differences in their understanding of terminology can potentially lead to business disputes as described above.

[0085] In this embodiment, the term "internal terminology" includes not only "company-specific terminology" used in for-profit organizations such as enterprises and their units, but also "terminology similar to company-specific terminology" used in non-profit organizations, communities, and their units, referred to as "internal terminology" in mainland China. Below, as an example of "internal terminology," we will use "company-specific terminology" applied to enterprises to illustrate this embodiment.

[0086] In this embodiment, in order to solve at least one of the aforementioned problems of conventional crowdsourcing, a matching system 1, which is described in detail below, is proposed.

[0087] [Overall Structure]

[0088] Reference Figure 1 The following describes the general structure of the matching system 1. The matching system 1 includes a shared server 100, recruiter devices 200A, 200B, 200C, etc., and applicant devices 300A, 300B, 300C, etc.

[0089] Shared Server 100 provides matching services to a large number of enterprises, enabling them to publish and accept business transactions. Figure 1 The example shown is of companies A, B, C, etc., utilizing 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 utilize Matching System 1, are also individually registered as members of Matching System 1.

[0090] The business described in Matching System 1 is, for example, a temporary business envisioned to be completed within a predetermined period. Therefore, individuals undertaking businesses described in Matching System 1 primarily engage in business within their specific department within the company, and secondarily engage in various other businesses. Furthermore, in Matching System 1, for example, applicants for company A can also undertake business from company A. Therefore, Matching System 1 also allows business from department X of company A to be undertaken by applicants from different departments Y belonging to company A.

[0091] Below, the business offered by a contractor in Matching System 1 is sometimes referred to as a "recruitment business," "recruitment case," or "business case." The person offering the recruitment case is sometimes referred to as the "recruiter," and the person offering the recruitment case is sometimes referred to as the "applicant." The situation of applying for a recruitment business is sometimes referred to as "applying for a recruitment business" or "applying for a recruitment case (business case)."

[0092] The applicant who takes on the recruitment case is equivalent to the "acceptor", and the recruiter who publishes the case to the acceptor is equivalent to the "publisher". However, sometimes the term "acceptor" is included in the text and is called "applicant" in mainland China, and sometimes the term "publisher" is included in the text and is called "recruiter" in mainland China.

[0093] A database 120, necessary for the matching service, is constructed within the shared server 100. Database 120 includes various databases that register information required to provide the matching service. For example, database 120 registers information such as membership details and recruitment information. The shared server 100 is managed and used by a different company than the one utilizing the matching service. Alternatively, the shared server 100 can be managed and used by any company utilizing the matching service.

[0094] Recruiter device 200A is operated by the manager of company A. Recruiter device 200B is operated by the manager of company B. Recruiter device 200C is operated by the manager of company C. Hereinafter, recruiter devices 200A, 200B, 200C, etc., are sometimes collectively referred to as "Recruiter Device 200".

[0095] Applicant device 300A is operated by applicants from company A. Applicant device 300B is operated by applicants from company B. Applicant device 300C is operated by applicants from company C. Hereinafter, applicant devices 300A, 300B, 300C, etc., are sometimes collectively referred to as "Applicant Device 300". Figure 1 The template shows two applicants for each company, but the number of applicants is not limited to this. There can be more applicants across companies, or only one applicant for a particular company. Shared Server 100 can also accept freelancers and other individuals not affiliated with a company as applicants.

[0096] In this embodiment, the managers of companies A, B, C, etc., act as recruiters. Therefore, the managers of each company are sometimes referred to as "recruiters" below. Recruiters can also act as applicants for services being recruited by other recruiters. In this case, recruiter device 200 functions as applicant device 300. In this embodiment, when a company's manager acts as a recruiter, the device used by that manager in utilizing the matching service is referred to as recruiter device 200.

[0097] Company A can have one or more managers. When assigning managers to Company A, each manager can be provided with a recruiter device 200, or multiple managers can share a single recruiter device 200. The same applies to Companies B, C, and so on.

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

[0099] When accepting access from recruiter device 200, shared server 100 requires login with a member ID and password. Similarly, when accepting access from applicant device 300, shared server 100 requires login with a member ID and password. Shared server 100 identifies each recruiter and applicant based on the member ID provided during login.

[0100] The recruiter device 200 handles various operations performed by recruiters. For example, it handles operations such as entering recruitment cases (commissioned business), entering evaluations of completed business handlers, and searching for members who match services.

[0101] The recruiter device 200 communicates with the shared server 100 based on various operations performed on the recruiter device 200. The shared server 100 registers recruitment cases (commissioned services) in the database 120 based on input of evaluations, registers evaluations of applicants (responsible persons) in the database 120 based on input of evaluations, and provides member information to the recruiter device 200 based on member retrieval operations.

[0102] The applicant device 300 handles various operations by applicants. For example, the applicant device 300 handles operations such as searching for recruitment cases, applying for recruitment cases, and entering business performance records.

[0103] The applicant device 300 communicates with the shared server 100 based on various operations performed on the applicant device 300. Based on the operation of retrieving recruitment cases, the shared server 100 provides appropriate recruitment cases to the applicant device 300; based on the operation of applying for recruitment cases, it sends acceptance or rejection notices to the applicant device 300; and based on the operation of inputting business performance, it registers the business performance in the database 120.

[0104] As described above, the matching system 1 includes an evaluation system for assessing applicants (subjects) for the business and a recruitment system for recruiting subject subjects for the business.

[0105] A recruiter in a department of company A can use matching system 1 to hire applicants from other departments of company A as recruiters. Similarly, a recruiter in company A can use matching system 1 to hire applicants from company B as recruiters.

[0106] The members of Matching System 1 will sometimes be referred to as "users". Additionally, the recruiter device 200 and the applicant device 300 operated by members will sometimes be collectively referred to as "user device 500". Users of Matching System 1 use "user device 500" to access shared server 100 as recruiters or applicants.

[0107] Various information is displayed on the user device 500. For example, when a user accesses the shared server 100 as an applicant, a list of business cases that the user can apply for is displayed on the user device 500. The user can select the case they want to apply for from the list of business cases. In particular, Figure 1 Screen 551 shows the "List of Cases Under Recruitment" displayed when a user registers with shared server 100 in administrator mode. By viewing the "List of Cases Under Recruitment," users can see all business cases publicly available to their company.

[0108] The "List of Cases for Recruitment" includes an area for users to set viewing restrictions for business cases. This area is not displayed when a user registers to shared server 100 in normal mode (excluding administrator mode). Users with administrator privileges can select cases from a large pool of business cases that they do not want their company's employees to view and set viewing restrictions for the selected cases. Cases with viewing restrictions set are no longer publicly available to the company of the user with administrator privileges.

[0109] Thus, in this embodiment, only users with administrator privileges can set access restrictions related to business cases. However, the system can also be configured so that only authorized users with administrator privileges can set access restrictions related to business cases. Alternatively, the system can be configured so that any user can set access restrictions related to business cases.

[0110] When a user accesses the shared server 100 from the perspective of a recruiter, the user can also display the applicant's profile on the user device 500. The user uses the user device 500 to review the applicant's work experience, etc. Alternatively, the user device 500 can display the recruitment highlights of the business. The user (applicant) views screen 552 of the user device 500 to review the details of the business. The user (recruiter) views screen 552 to review the applicant's work experience, etc. Alternatively, screen 552 can display reports related to the ongoing business, instructions to change part of the entrusted content, instructions to add entrusted content, etc. The user confirms the content displayed on screen 552 and performs necessary processing such as replying to the other party using the user device 500.

[0111] The recruitment guidelines, job experience, business reports, and instructions displayed in screen 552 may contain company terminology. If the company viewing screen 552 belongs to a different company than the company providing this information, the user viewing screen 552 may not be able to correctly understand the company's internal terminology.

[0112] Therefore, matching system 1 registers the company terminology and its meanings for each enterprise in database 21. Matching system 1 generates an index related to company terminology based on articles such as recruitment guidelines used by users, and links this index to the company terminology registered in database 21. In this way, matching system 1 has an indexing function.

[0113] If the text displayed on screen 552 contains company terminology, the user device 500 displays the company terminology in a different way than other terminology. Thus, the user understands that it is company terminology. Furthermore, the user device 500 displays the meaning of the company terminology on screen 552 based on the user's actions (e.g., clicking on the section containing the company terminology).

[0114] For example, in Figure 1 Screen 552 shows an example of "DX" as an internal company term. "DX" is underlined to indicate that it is an internal term. The user clicks on "DX." Screen 552 then displays a window explaining the meaning of the term "DX." DX is an abbreviation for Digital Transformation, which usually means transformation using digital technologies. However, depending on the company, "DX" may be used internally to mean creating new value regardless of whether digital technology is used. In this case, the window in screen 552 explains the meaning corresponding to that internal term. Thus, the user can correctly understand the meaning of "DX" as intended.

[0115] Figure 2This is a block diagram showing the structure of the shared server 100, the recruiter device 200, and the applicant device 300.

[0116] [Structure of Shared Server 100]

[0117] The shared server 100 includes a processor 101, a memory 102, a storage device 103, and a communication interface 104.

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

[0119] Storage device 103 consists of hard disk drives and solid-state drives, etc. Database 120 is stored in storage device 103. Database 120 includes multiple types of databases. These multiple types of databases include a corporate database (corporate DB) 121, a member database (member DB) 122, a community database (community DB) 123, a recruitment case database (recruitment case DB) 124, a side hustle database (side hustle DB) 125, an evaluation input database (evaluation input) 126, and an evaluation summary database (evaluation summary DB) 127.

[0120] Alternatively, a portion of these various databases can be stored in a storage device separate from the shared server 100. For example, it can also be connected to a cloud service independent of the shared server 100 to... Figure 2 Some of the various types of databases shown are stored in the cloud. In this case, the shared server 100 can access the required databases by communicating with the cloud via the Internet 50.

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

[0122] [Structure of Recruiter Device 200]

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

[0124] The memory 202 includes RAM (Random Access Memory), ROM (Read Only Memory), flash memory, or any other suitable memory system. The memory 202 stores programs required for the processing of the processor 201, as well as temporary data calculated during the processing.

[0125] Processor 201 connects to Internet 50 via communication interface 203 according to a program stored in memory 202. Processor 201 communicates with sharing server 100 via Internet 50. Processor 201 communicates with sharing server 100 to perform tasks such as sending recruitment applications, displaying information of members as applicants on display 205, posting services to selected contractors from applicants, and sending evaluations of contractors input by recruiters to sharing server 100.

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

[0127] [Structure of the Applicant Device 300]

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

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

[0130] 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 communicates with the shared server 100 via the Internet 50. The processor 301 communicates with the shared server 100 to process recruitment applications, display acceptance or rejection notices for the applications on the display 305, and send the performance data of the accepted business to the shared server 100.

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

[0132] [Summary of Database 120]

[0133] The following is an overview of database 120. Enterprise database 121 contains information about enterprises that have joined matching system 1. Member database 122 contains information about members who use matching system 1. Many members are employees of the enterprises that have joined matching system 1.

[0134] Members registered in member database 122 can act as recruiters (posters) or applicants (receivers) through matching system 1. Members may include not only employees of companies registered in enterprise database 121, but also individuals (freelancers) who are not affiliated with companies.

[0135] The community database 123 stores information used to identify companies belonging to a community. Communities are formed through agreements between companies. Therefore, multiple communities can be formed depending on the method of agreement between companies. The number of companies belonging to a community can also be arbitrarily set. Companies with community relationships form trust relationships within the scope determined by the agreement reached when the community was formed. The community database 123 registers information for each community to identify the companies belonging to that community.

[0136] The recruitment case database 124 contains businesses (recruitment cases) that recruit contractors. Employees of various companies can, while performing their primary duties within their respective departments, also act as members of matching system 1 to take on cases from other departments within their own company or from other companies that are registered in the recruitment case database 124. In this case, members take on cases from other departments within their own company or from other companies as secondary work.

[0137] In the Side Hustle Database 125, each member has registered data indicating the status of their side hustle. This data includes information such as side hustle performance and plans.

[0138] The evaluation input database 126 contains information on evaluations of applicants (subjects) for business opportunities. The business recruiter (issuer) can use the matching system 1 to act as an evaluator, assessing the performance of applicants (subjects) who have completed their business. The evaluations conducted by each evaluator are recorded in the evaluation input database 126.

[0139] Evaluation summaries are registered in evaluation summary database 127. Evaluation summaries are registered by member in evaluation summary database 127. Recruiters can view evaluation summaries. Recruiters can view the evaluation summaries of members who have applied for recruitment cases and select members they deem suitable as recipients.

[0140] [Enterprise Database 121]

[0141] Figure 3 This diagram illustrates an example of a corporate database 121. In corporate database 121, each corporate is registered with a corporate ID, corporate name, corporate address, and a maximum side-hustle time limit. The maximum side-hustle time limit is the maximum permitted time for employees to engage in side-hustle activities in addition to their primary job. The maximum side-hustle time limit is determined for each individual company. For example, the maximum side-hustle time limit can be calculated as "stipulated overtime hours - overtime hours in the primary job outside of the side-hustle." "Stipulated overtime hours" varies from company to company. Furthermore, in... Figure 3 The text shows the maximum side hustle time in months, but it can also be set in weeks. The unit for the maximum side hustle time can also be determined for each individual business.

[0142] In this implementation, members are allowed to apply for business from various companies and departments within a time limit not exceeding the maximum time limit for side jobs determined by the company to which the member belongs.

[0143] [Member Database 122]

[0144] Figure 4 This diagram illustrates an example of a member database 122. Member database 122 contains various information about members. This information includes a member ID used to identify the member, the ID of the company the member belongs to, the member name, the member's permissions, the department the member belongs to, and the permitted hours for engaging in side jobs.

[0145] Member permissions are categorized as administrators and applicants. Members with administrator permissions are granted the ability to utilize Matching System 1 as both recruiters and applicants. Members with applicant permissions are granted the ability to utilize Matching System 1 as applicants, but not as recruiters. Department heads within the company are granted administrator permissions to manage the side-work status of their subordinates. Administrators with administrator permissions are granted the ability to approve applications from their subordinate applicants. Thus, administrators function as approvers.

[0146] Available side hustle time is the remaining time that can be spent on a side hustle. It is calculated as "maximum side hustle time - total side hustle time". If the applicant is engaged in multiple side hustles, the total side hustle time includes the time already spent on each of these side hustles. In addition to the time already spent on side hustles, the total side hustle time also includes the estimated time for the side hustle. The estimated side hustle time is calculated based on the projected working hours registered in the recruitment case database 124. Figure 4The available hours for side jobs are shown in monthly units. For applicants searching for recruitment opportunities using matching system 1, only jobs that can be handled within the range of available hours are considered eligible.

[0147] [Community Database 123]

[0148] Figure 5 This diagram illustrates an example of community database 123. Community database 123 registers information about communities formed between enterprises. The community information includes a community ID, community name, and a list of enterprise IDs to which the community belongs. Enterprises can form various communities by reaching agreements with other enterprises. Enterprises belonging to a community can change the target enterprises of that community by reaching agreements with other enterprises.

[0149] [Recruitment Case Database 124]

[0150] Figure 6 This diagram illustrates an example of a recruitment case database 124. Recruitment case database 124 contains information about recruitment cases. This information includes a case ID used to identify the recruitment case, the ID of the company to which the recruiter registered the recruitment case belongs, a list of non-public company IDs, the recruiter's member ID, public access level, restrictions, case title, projected working hours, projected period, and case content.

[0151] For example, the list of non-public company IDs includes company IDs that are prohibited from publicly recruiting. The disclosure level is set to any one of three levels: "Our Company," "Within the Community," and "All." When the disclosure level is set to "All," the target audience also includes applicants outside the community. Restricted information is related to... Figure 1 The information shown pertains to browsing restrictions. These restrictions are set by the applicant's company for each recruitment case.

[0152] exist Figure 6 The right side of the recruitment case database 124 displays the IDs of the companies that can browse the recruitment cases. For example, for the recruitment case corresponding to case ID=001, the public access level is set to "Our Company". In this case, only members belonging to the company that registered the recruitment case (Company ID=00A) can browse the recruitment case corresponding to case ID=001.

[0153] Below, sometimes the case ID is used to refer to the recruitment cases corresponding to each case ID as Case 001, Case 002, Case 003, etc. Similarly, sometimes the community ID is used to refer to the communities corresponding to each community ID as Community 01, Community 02, Community 03, etc., and sometimes the member ID is used to refer to the members corresponding to each member ID as Member P1, Member P2, Member P3, etc. Additionally, sometimes a portion of the enterprise ID is used to refer to the enterprises corresponding to each enterprise ID as Enterprise A, Enterprise B, Enterprise C, etc.

[0154] For Case 002, the public access level was set to "within the community". According to Figure 5 The community database 123 shown has community relationships with company A (registered case 002) as companies B and C. Therefore, as... Figure 6 As shown, only members belonging to any of the three companies, namely Company A, Company B, and Company C, can view Case 002.

[0155] However, if Company B's management sets viewing restrictions on Case 002, the recruitment case database 124 contains restriction information that limits Company B members' access to Case 002. In this case, only members belonging to Company A or any of Company C can view Case 002.

[0156] The registered company and public disclosure level of Case 003 are the same as those of Case 002. However, for Case 003, "00B" is registered in the list of non-public company IDs. Therefore, as... Figure 6 As shown, only members belonging to either Company A or Company C can view Case 003; members belonging to Company B are not granted permission to view Case 003.

[0157] When the public access level is set to "all" for recruitment cases, all members will be able to view the recruitment cases that are targeted at them. Figure 6 Case 005 shown matches this recruitment case. Assuming that one or more company IDs are registered in the non-public company ID list for Case 005, members belonging to those companies will not be granted access to view Case 005.

[0158] The applicant and the matching system 1 use the assumed working hours and assumed period to assume the time required to process the recruitment case.

[0159] Furthermore, various variations can be considered regarding the setting of disclosure levels. For example, users could be able to control the disclosure targets of business information by selecting specific items. More specifically, a checkbox for selecting companies to disclose business information could be set on the screen used to register recruitment cases. Alternatively, users could be able to control related information and functions by selecting an option from a predefined set of options. For example, the screen used to register recruitment cases could display a list allowing users to select the scope of disclosure for business information from "Within Our Company," "Within the Community," and "All Users."

[0160] User device 500 can also provide users with a setting screen for setting the disclosure level to various levels. For example, the setting screen can also display checkboxes for users to select the object of the disclosure case by industry type such as "pharmaceuticals", "chemicals", "electrical equipment", "railways and buses", "food", etc. Furthermore, it can be configured so that by displaying the company names corresponding to each industry type in the setting screen, users can select the object of the disclosure case by "industry type" and by "company".

[0161] For example, as companies corresponding to "pharmaceuticals", there are Company A, Company B, Company C and Company D; as companies corresponding to "chemicals", there are Company E, Company F, Company G and Company H; and as companies corresponding to "electrical equipment", there are Company I, Company J, Company K and Company L.

[0162] In this case, the setup screen displays the companies listed under the "Pharmaceuticals" industry type, from "Company A" to "Company D," with checkboxes corresponding to "Pharmaceuticals," "Company A," "Company B," "Company C," and "Company D," respectively. Similarly, the setup screen displays the companies listed under the "Chemistry" industry type, from "Company E" to "Company H," with checkboxes corresponding to "Chemistry," "Company E," "Company F," "Company G," and "Company H," respectively. Finally, the setup screen displays the companies listed under the "Electrical Equipment" industry type, from "Company I" to "Company L," with checkboxes corresponding to "Electrical Equipment," "Company I," "Company J," "Company K," and "Company L," respectively.

[0163] For example, suppose a user selects the checkboxes corresponding to "Pharmaceuticals" and "Chemicals," but does not select the checkbox corresponding to "Electrical Equipment." In this case, the "Electrical Equipment" industry type is excluded from the scope of the publicly disclosed case. Furthermore, suppose a user selects the checkboxes corresponding to companies A through C (belonging to "Pharmaceuticals") and companies E through H (belonging to "Chemicals"), but does not select the checkbox corresponding to company D (belonging to "Pharmaceuticals"). In this case, companies A through C (belonging to "Pharmaceuticals") and companies E through H (belonging to "Chemicals") are considered subjects of the publicly disclosed case, but company D (belonging to "Pharmaceuticals") is excluded.

[0164] [Side Hustle Database 125]

[0165] Figure 7 This is a diagram illustrating an example of a side hustle database 125. In the side hustle database 125, information indicating the status of a member's side hustle is registered by case. This information includes the member's ID, case ID, month (the period during which the side hustle was performed), planned side hustle time, actual side hustle performance time, estimated side hustle time, and progress rate.

[0166] The planned side hustle time is the time a member is expected to spend handling the cases they have taken on. Members who have taken on side hustles input their planned side hustle time monthly from their recruiter device 300. The input planned side hustle time is reflected in the side hustle database 125. For example, the projected working hours for case 001 are set at 5 hours / person / month in the recruitment case database 124. This means that it is 5 hours of work per person per month. Generally, members input their planned side hustle time based on the projected working hours of the recruited cases.

[0167] Side hustle performance time refers to the actual time a member has spent working on a case they have accepted. In other words, side hustle performance time is the time a member has actually worked. Before a case is completed, each time a member works on a case, they input the time spent working on that case using their applicant device 300 at any given time. In the side hustle database 125, the cumulative value of the time input using the applicant device 300 is recorded monthly as side hustle performance time.

[0168] The side hustle estimated time is the time envisioned for the business of the case being pursued. In other words, the side hustle estimated time is the estimated time for a member's future work. The shared server 100 automatically sets the side hustle estimated time by considering the side hustle planning time and the side hustle performance time. Alternatively, members can input the side hustle estimated time at any time before the completion of the business of the case being pursued using their applicant device 300. Furthermore, members can also temporarily modify the automatically set side hustle estimated time. It is desirable that the side hustle estimated time be less than the side hustle planning time. However, depending on the circumstances of the case, the side hustle estimated time may also be longer than the side hustle planning time. Alternatively, members undertaking the case can update the side hustle estimated time at any time before the completion of the business of the case.

[0169] The progress rate indicates the degree of progress of the side hustle. The progress rate is entered based on the judgment of the person engaged in the side hustle. For example, enter the progress rate between 0 (%) and 100 (%).

[0170] For example, when a member initially takes on a case, the progress rate is 0%, the side hustle performance time is 0 hours, and the planned side hustle time matches the estimated side hustle time. As the member progresses with the case and inputs the side hustle performance time and progress rate, the estimated side hustle time changes accordingly.

[0171] exist Figure 7 The side hustle database 125 shown displays side hustle data for member P2 from October 2021 to December 2021. (Refer to...) Figure 7 As shown in the side hustle database 125, member P2 engaged in Case 001 and Case 002 between October 2021 and December 2021.

[0172] For October data related to Case 001, the side hustle database 125 recorded a side hustle planned time of 5, actual side hustle performance time of 10, and estimated side hustle time of 10. Therefore, it can be concluded that member P2 engaged in Case 001 for longer than the planned side hustle time in October.

[0173] For November data related to Case 002, the side hustle database 125 recorded a side hustle planned time of 10 days, actual side hustle performance time of 4 days, and estimated side hustle time of 8 days. This indicates that member P2 completed Case 002 within the set estimated side hustle time in November. The progress rate of 50% indicates that member P2 completed half of the entire business for Case 002 in November.

[0174] For December data in Case 001, the side hustle database 125 recorded a side hustle plan time of 5 and an estimated side hustle time of 5, but no actual side hustle performance time was recorded. Similarly, for December data in Case 002, no actual side hustle performance time was recorded. This means that we are waiting for member P2 to input the actual side hustle performance time.

[0175] The shared server 100 uses the side hustle database 125's estimated side hustle time and actual side hustle performance time to calculate the spare capacity members can have for additional side hustles. When a member is engaged in multiple side hustles, the shared server 100 calculates the total estimated side hustle time ("total estimated side hustle time") and the total actual side hustle performance time ("total actual side hustle performance time"). The shared server 100 calculates the spare capacity for side hustles by calculating "side hustle cap time - (total estimated side hustle time + total actual side hustle performance time)". Here, when "total estimated side hustle time + total actual side hustle performance time" is defined as "total side hustle time", the spare capacity for side hustles, i.e., "available side hustle time," is calculated using "side hustle cap time - total side hustle time". For example, in... Figure 7 In the side hustle database 125 shown, member P2's total estimated side hustle time for December is 15 hours (5 hours + 10 hours). However, member P2's total actual side hustle performance time for December is zero. If the "side hustle time cap" determined by member P2's company is 30 hours, then member P2's spare time (available side hustle time) is calculated as 15 hours (30 hours - 15 hours).

[0176] Here is an example illustrating a more detailed calculation process for the estimated time of a side hustle. For instance, the "estimated time of a side hustle" can also be calculated based on the formula "(work progress rate / progress rate) × planned time of the side hustle - actual time of the side hustle". Here, the "work progress rate" is calculated by "actual time of the side hustle / planned time of the side hustle". As already explained, the "progress rate" is the progress rate entered into the side hustle database 125 based on the judgment of the person engaged in the side hustle.

[0177] For example, if the planned side hustle time is 10 hours and the actual side hustle performance time is 2 hours, the progress rate is calculated as 20%. Here, we set the progress rate to 40%. In this case, the estimated side hustle time is calculated as "(20% / 40%)×10 hours-2 hours"=3 hours. That is, according to the calculation result, the estimated side hustle time is 3 hours.

[0178] [Evaluation input database 126]

[0179] Figure 8This diagram illustrates an example of an evaluation input database 126. The evaluation input database 126 records information about the evaluations of the evaluated. This evaluation information includes the evaluated object, the evaluated person's member ID, the evaluator's member ID, and the evaluation result.

[0180] The evaluation input database 126 includes a recruiter evaluation department 126A and an applicant evaluation department 126B. The recruiter evaluation department 126A records evaluations of recruiters (posters). The applicant evaluation department 126B records evaluations of applicants (responsible persons).

[0181] In Recruiter Evaluation Department 126A, the recruiter (poster) is equivalent to the evaluation target (evaluated party), and the applicant who undertakes the recruitment work for the evaluation target is equivalent to the evaluator. In Recruiter Evaluation Department 126A, evaluations of the evaluated parties are registered by the evaluators. Figure 8 The example shown illustrates how members P1 and P2, who are essentially the evaluated, received evaluations from the evaluator members. Specifically, in... Figure 8 The example shown illustrates how member P1 received evaluations from members P5, P7, P11, and P12. The evaluation results (evaluation values) are represented by a value where 10 is the maximum and 0 is the minimum.

[0182] In the Applicant Evaluation Department 126B, the applicant (the recipient) of a recruitment case is equivalent to the evaluation subject (the person being evaluated), and the recruiter (the publisher) of the case is equivalent to the evaluator. In the Applicant Evaluation Department 126B, evaluations of the evaluated persons are registered by the evaluators. Figure 8 The example shown illustrates how member P7, equivalent to the person being evaluated, received evaluations from members P1, P2, and P3, equivalent to the evaluators. Furthermore, in... Figure 8 Examples of evaluation results from the applicant evaluation section 126B are omitted here, but various evaluation results are recorded here in the same way as in the recruiter evaluation section 126A.

[0183] When a job seeker (contractor) completes a job they have taken on from a recruiter (publisher), they use the job seeker device 300 to evaluate the recruiter (contractor). The evaluator's evaluation results are recorded in the evaluation input database 126. If a job seeker takes on another job from a recruiter they have previously worked with, the job seeker evaluates that recruiter again. In this case, the average of the previous and subsequent evaluation results is recorded in the evaluation input database 126.

[0184] When a job seeker (contractor) completes the work entrusted to them, the recruiter (publisher), acting as an evaluator, uses recruiter device 200 to evaluate the job seeker (evaluator). The evaluator's evaluation results are recorded in evaluation input database 126. If a recruiter re-assigns other work to a job seeker who has previously been entrusted with work, the recruiter evaluates that job seeker again. In this case, the average of the previous and subsequent evaluation results is recorded in evaluation input database 126.

[0185] Therefore, the evaluation results registered in the evaluation input database 126 reflect the average evaluation of the evaluated party by each evaluator. Alternatively, a weighted average calculated from the number of evaluations and a deviation value can be used instead of the average. The evaluation results for each case ID can also be registered in the evaluation input database 126.

[0186] [Evaluation Summary Database 127]

[0187] Figure 9 This is a diagram illustrating an example of an evaluation summary database 127. The evaluation summary database 127 records evaluation information for the evaluated entity by department. The information for evaluations by organization includes the evaluated entity, the evaluated entity's member ID, the evaluated entity's company ID, the evaluator's company ID, the evaluator's department, and the evaluation summary.

[0188] The evaluation summary database 127 includes a recruiter evaluation summary section 127A and an applicant evaluation summary section 127B. In the recruiter evaluation summary section 127A, the recruiter (poster) is equivalent to the evaluation target (the person being evaluated). In the applicant evaluation summary section 127B, the applicant (receiver) is equivalent to the evaluation target (the person being evaluated). The evaluation summary database 127 records evaluation summaries for each evaluation target, organized by department.

[0189] The evaluation summary is calculated based on the statistical results of the evaluation input database 126. The department categories include various departments within the company, such as the "Systems Department" and "Planning Department," as well as the "Entire Company," which represents the company as a whole. The evaluation summary is calculated according to these "departments."

[0190] exist Figure 9 In section 127A, which serves as the recruiter's evaluation summary, an example is shown where member P1 is equivalent to the evaluated party. The evaluated party's company ID is "00A". Therefore, member P1 belongs to company A. Figure 9 In the dataset, data set 1271 represents company B's evaluation of member P1 acting as a recruiter, and data set 1272 represents company C's evaluation of member P1 acting as a recruiter.

[0191] Referring to data set 1271, the evaluations of Company B are categorized into evaluations of the company as a whole, evaluations of the systems department within Company B, and evaluations of the planning department within Company B. The evaluation summary records the average values ​​of the evaluations corresponding to each categorized category.

[0192] For example, as an evaluation summary corresponding to Enterprise B as a whole, it records the average evaluation results of Enterprise B's members who evaluated member P1, who acted as a recruiter. Figure 9 In this context, the value is set to "4.75". As an evaluation summary corresponding to the System Department, it records the average evaluation results of members of Company B belonging to the System Department who evaluated member P1, who acted as a recruiter. Figure 9 In this context, the value is set to "4.0". As an evaluation summary corresponding to the Planning Department, it records the average evaluation results of members of Company B belonging to the Planning Department who evaluated member P1, who acted as a recruiter. Figure 9 In this context, the value is set to "5.0".

[0193] For data set 1272, similarly to data set 1271, the evaluation of company C is categorized into evaluations of the company as a whole and evaluations of individual departments within company C. Data sets 1271 and 1272 contain data on recruiters as the evaluation subjects. Therefore, the evaluation summaries registered in data sets 1271 and 1272 are recruiter evaluation summaries.

[0194] The recruiter evaluation summary section 127A has been described in detail above. Next, the applicant evaluation summary section 127B will be described. Figure 9 In the example shown in the Applicant Evaluation Summary Section 127B, member P7 is equivalent to the evaluated party. The evaluated party's company ID is "00C". Therefore, member P7 belongs to company C. In the Applicant Evaluation Summary Section 127B, evaluations of member P7 acting as an applicant are registered by department.

[0195] The applicant evaluation summary section 127B has the same structure as the recruiter evaluation summary section 127A, except that the evaluation object is "applicant" rather than "recruiter". Therefore, the description of the applicant evaluation summary section 127B will be replaced by the description of the recruiter evaluation summary section 127A that has already been carried out.

[0196] Shared server 100 uses the evaluation input database 126 to determine the evaluation results for each member and uses the member database 122 to determine the affiliation of each member. Based on these determinations, shared server 100 updates the data in the evaluation summary database 127.

[0197] In addition, Figure 9In this example, only members P1 and P7 are shown as the evaluated entities, but other members P2-P6, P8, and P9 are also registered in the evaluation summary database 127 as evaluated entities. The evaluation summary database 127 may also include data on the same member being both a recruiter and an applicant, designated as an evaluation subject. For example, it may also include... Figure 9 In the evaluation summary database 127 shown, in addition to the recruiter evaluation summary related to member P1, the applicant evaluation summary related to member P1 is also registered.

[0198] [Functions of shared servers, recruiter devices, and applicant devices]

[0199] Figures 10-12 This diagram illustrates the functions of the shared server, recruiter device, and applicant device.

[0200] like Figure 10 As shown, the shared server 100 functionally includes a community registration department 140, a business registration department 141, a member registration department 142, a member retrieval department 143, and a case registration department 144. These various functions are implemented through the processor 101, memory 102, storage device 103, and communication interface 104 of the shared server 100.

[0201] Community registration unit 140 has the function of registering communities in community database 123. The system administrator of the matching system 1 uses the keyboard and other operation units (figure omitted) to input community-related information into the shared server 100.

[0202] The information related to the community includes the community name and information about the company to which the community belongs. The community registration department 140 registers the community in the community database 123 according to the input of the system administrator (step S1). The community registration department 140 also has the function of updating the information of the communities registered in the community database 123.

[0203] The Business Registration Department 141 has the function of registering new businesses joining the Matching System 1. System administrators use keyboards and other operating devices to input business-related information into the shared server 100.

[0204] Information related to the enterprise includes the enterprise name, address, and maximum permitted time for side businesses. The enterprise registration department 141 registers the enterprise in the enterprise database 121 according to the input from the system administrator (step S2). The enterprise registration department 141 also has the function of updating the information of registered enterprises.

[0205] Membership Registration Department 142 has the function of registering new members to join Matching System 1. Membership Registration Department 142 issues member IDs and passwords based on requests from individuals belonging to companies that have joined Matching System 1. Individuals wishing to become members use personal computers or similar devices to perform the registration process (step S3).

[0206] Specifically, individuals wishing to become members input their name, company, and department information into their personal computers and send the input to the shared server 100. The membership registration department 142 registers the input information in the membership database 122. New members can then log in to the shared server 100 using the personal computer used for membership registration. In this case, the personal computer functions as either a recruiter device 200 or a job seeker device 300.

[0207] exist Figure 10 The diagram illustrates two applicant devices 300. One applicant device is conceived to be operated by the manager of the applying company. The other applicant device is conceived to be operated by someone in the applying company other than the manager. The manager of the applying company holds a management position such as a department head, and is equivalent to the superior of the applicants who are subordinates. In this embodiment, the manager of the applying company assumes the role of approver of the applicants' applications for the recruitment case.

[0208] The member retrieval unit 143 has the function of retrieving members of the matching system 1. In response to requests from the recruiter device 200 and the applicant device 300, the member retrieval unit 143 provides the recruiter device 200 and the applicant device 300 with information of members registered in the member database 122.

[0209] When recruiter device 200 receives a search operation from a recruiter, it performs member search processing (step S4A). This allows the recruiter to browse applicants' information, for example. The recruiter can then consider the applicants' information to select the person who will handle the business from among multiple applicants. Similarly, when applicant device 300 receives a search operation from a manager who is equivalent to an applicant's superior, it performs member search processing (step S4A).

[0210] Furthermore, upon receiving a search request from an applicant, the applicant device 300 performs a member search process (step S4B). This allows the applicant, for example, to browse recruiter information. The applicant can then consider the recruiter's information to select the desired service from multiple recruitment opportunities.

[0211] Regarding the member retrieval process (step S4A) performed by the recruiter device 200 and the processing of the member retrieval unit 143, the following will use... Figure 19This will be explained in detail. The member search process (step S4B) performed by the applicant device 300 and the processing of the member search unit 143 will be discussed later. Figure 20 Let me explain in detail.

[0212] The case registration unit 144 has the function of registering recruitment cases in the recruitment case database 124. When the recruiter device 200 receives an input recruitment case, it performs the recruitment case registration process (step S5). During the recruitment case registration process, the recruiter device 200 sends the recruitment case information to the shared server 100. The case registration unit 144 registers the received recruitment case information in the recruitment case database 124.

[0213] Regarding the recruitment case registration process (step S5) performed by the recruiter device 200 and the processing of the case registration department 144, the following will use... Figure 14 Let me explain in detail.

[0214] like Figure 11 As shown, the shared server 100 functionally includes a case retrieval unit 145, an application unit 146, an approval unit 147, and a notification unit 148. These various functions are implemented through the processor 101, memory 102, storage device 103, and communication interface 104 provided by the shared server 100.

[0215] The Case Extraction Department 145 has the function of extracting recruitment cases that applicants can view. The Application Department 146 has the function of requesting an applicant's application from the manager (the applicant's superior). The Approval Department 147 has the function of sending the application details for the recruitment case to the recruiter on the condition that approval for the application is received from the manager (approver). The Notification Department 148 has the function of receiving the result of whether the applicant has been hired from the recruiter and notifying both the applicant and the manager of the result.

[0216] The application department 146, approval department 147, and notification department 148 use a workflow system to request approval from managers, notify recruiters of applicants, and notify applicants of application results.

[0217] When the applicant device 300 receives an applicant's request to retrieve recruitment cases, it performs recruitment case retrieval processing (step S6). In the recruitment case retrieval processing, the applicant device 300 sends a retrieval request to the case extraction unit 145 of the shared server 100.

[0218] Upon receiving a search request, the case extraction unit 145 extracts cases that are accessible to applicants from the recruitment cases registered in the recruitment case database 124 and sends the extracted cases to the applicant device 300. The case extraction unit 145 determines whether a case is accessible to the applicant based on a first criterion and a second criterion. The first criterion is the scope of disclosure for the recruitment case. The second criterion is the applicant's spare capacity in their side hustle. The scope of disclosure is determined by... Figure 14 The publicly available information shown determines this. The spare time from side hustles... Figure 15 The available time for a side job is calculated based on the indicated available time.

[0219] The case extraction unit 145 determines cases that meet both the first and second criteria as cases that applicants can view. Therefore, the case extraction unit 145 extracts cases from the recruitment case database 124 that are allowed to be disclosed to applicants who have received a search request. Furthermore, the case extraction unit 145 extracts cases from the recruitment case database 124 that applicants who have received a search request can handle within their available time for side jobs. The case extraction unit 145 sends the cases that applicants can view to the applicant device 300.

[0220] Alternatively, the case retrieval unit 145 may accept the operation of setting the criteria for retrieving cases. For example, the shared server 100 may be supplemented with a function that allows the system administrator to select any of the following settings: a first setting that only sets the first criterion to be valid, a second setting that only sets the second criterion to be valid, and a third setting that sets both the first and second criterions to be valid.

[0221] The applicant device 300 receives recruitment cases from the case retrieval unit 145. The applicant device 300 displays the received recruitment cases on the display 305 (step S7).

[0222] Furthermore, the processes for recruiting cases (step S6), displaying recruiting cases (step S7), and the processing of the case extraction unit 145 will be used later. Figure 15 Let me explain in detail.

[0223] The applicant selects a candidate from the recruitment cases displayed on the display screen 305 using the applicant device 300. The applicant device 300 then performs an application process (step S8) based on the applicant's action. During the application process, the applicant device 300 sends application information indicating a candidate to the application department 146 of the shared server 100. This sends a request for business from the applicant device 300 to the application department 146.

[0224] The application unit 146 sends the application information received from the applicant device 30 to the manager's (applicant's superior) applicant device 300. The application unit 146 determines the member ID of the manager, for example, based on the relationship between the applicant's member ID registered in the member database 122 and the superior's member ID. The application unit 146 sends the subordinate's application information to the applicant device 300 corresponding to the determined superior's member ID. The manager confirms the application submitted by the subordinate in their own applicant device 300. The manager performs an operation to approve the application in the applicant device 300. 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 approval information to the approval unit 147 of the shared server 100. Thus, approval information, as an example of an approval notification, is sent from the manager's (approver's) applicant device 300 to the approval unit 147.

[0225] The approval unit 147 accepts an applicant's application upon receiving approval information from the applicant device 300. Thus, in this embodiment, an applicant's application is accepted only upon approval by their manager. Therefore, managers can confirm in advance the content of the recruitment activities their subordinates wish to apply for. As a result, it is possible to prevent confidential information from being leaked outside the company through employees' side activities.

[0226] In addition, Figure 11 The diagram illustrates the process of a manager approving an application. Assuming that an application is rejected in step S9, a rejection message is sent from the manager's applicant device 300 to the approval unit 147. The approval unit 147 may also, upon receiving the rejection message, notify the applicant's applicant device 300 that the application has been rejected.

[0227] The approval unit 147, having received the applicant's application, sends the application information to the recruiter device 200. The application information includes the applicant's information and the details of the business being applied for. The recruiter device 200 displays the application details on the display 205 (step S10). Based on the display on the display 205, the recruiter confirms the applicant and the applied business, and determines whether to hire the applicant.

[0228] The recruiter inputs the result of their decision to hire or not hire to the recruiter device 200. The recruiter device 200 accepts the input result (step S11). The recruiter device 200 sends the received hiring or not hiring result to the notification unit 148 of the shared server 100.

[0229] Upon receiving the hiring or non-hiring result from the recruiter device 200, the notification unit 148 sends the hiring result (hiring or non-hiring result) to the applicant's applicant device 300 and the manager's applicant device 300.

[0230] The applicant's applicant device 300 and the manager's applicant device 300 display the application results on the display 305 (steps S12 and S13). The applicant and the manager confirm the application results by viewing the display on the display 305.

[0231] like Figure 12 As shown, the shared 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 implemented through the processor 101, memory 102, storage device 103, and communication interface 104 provided by the shared server 100.

[0232] The performance processing unit 149 is capable of processing the side hustle plan time and side hustle performance time entered by the applicant in the applicant device 300. The performance output unit 150 is capable of outputting information containing the applicant's side hustle plan time and side hustle performance time to the recruiter device 200 or the manager's applicant device 300.

[0233] The evaluation receiving unit 151 is equipped with the function of receiving evaluations of the applicant (recipient) input by the recruiter into the recruiter device 200. The evaluation output unit 152 is equipped with the function of outputting information representing the evaluation of the applicant to the recruiter device 200.

[0234] When applicants are engaged in side hustles, they input the planned time and actual performance time of the side hustle into the applicant device 300. Applicants typically input the planned time for a new side hustle into the applicant device 300, and input the actual performance time at random intervals during the period of engaging in the side hustle. For example, if an applicant undertakes a side hustle with a projected period spanning multiple months, they input the actual performance time of the side hustle into the applicant device 300 each month.

[0235] The applicant device 300 accepts the input of the side hustle plan time and side hustle performance time (step S14). The applicant device 300 sends the accepted side hustle plan time and side hustle performance time to the performance acceptance unit 149 of the shared server 100.

[0236] The performance acceptance unit 149 registers the received side hustle plan time and side hustle performance time into the side hustle database 125. The processing of step S14 performed by the applicant device 300 and the processing of the performance acceptance unit 149 will be discussed later. Figure 16 Let me explain in detail.

[0237] The performance output unit 150 sends the side hustle plan time and side hustle performance time registered in the side hustle database 125 to the recruiter device 200 and the manager's applicant device 300. The recruiter device 200 displays the received side hustle plan time and side hustle performance time on the display 205, and the manager's applicant device 300 displays the received side hustle plan time and side hustle performance time on the display 305 (step S15). When comparing the information sent to the recruiter device 200 with the information sent to the manager's applicant device 300, the cases to which the information was sent differ.

[0238] The performance review department 149 sends data corresponding to cases handled by subordinates from among many cases registered in the side hustle database 125 to the manager's applicant device 300. The manager can check the subordinates' side hustle status by viewing the display 305. Furthermore, the screen displayed on the manager's applicant device 300 when the manager checks the subordinates' side hustle status will be discussed later. Figure 23 To explain.

[0239] The performance review unit 149 sends data to the recruiter device 200, corresponding to cases recruited by the recruiter from among many cases registered in the side hustle database 125. For example, in Figure 7 In the side hustle database 125 shown, we consider the case where the first recruiter recruited for case 001 and the second recruiter recruited for case 002.

[0240] In this case, various data corresponding to case 001 from the side-job database 125 are sent from the performance processing 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 also sent from the performance processing unit 149 to the recruiter device 200 operated by the second recruiter.

[0241] The first recruiter and the second recruiter can check the progress of their cases by browsing the side hustle plan time and side hustle performance time displayed on the monitor 305 of the recruiter device 200.

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

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

[0244] Regarding the processing of step S16A performed by the recruiter device 200 and the processing of the evaluation receiving unit 151, the following will be used... Figure 17 Let me explain in detail.

[0245] When the recruiter device 200 receives an operation requesting the recruiter to browse the evaluations of applicants, it executes a browsing request process (step S17A). In this process, the recruiter device 200 sends a browsing request to the evaluation output unit 152 of the shared server 100. In response to the browsing request, the evaluation output unit 152 sends the applicant evaluations (applicant evaluation summaries) registered in the evaluation summary database 127 to the recruiter device 200. The recruiter device 200 then displays the received applicant evaluations on the display 205 (step S18A).

[0246] The processing of steps S17A and S18A performed by the recruiter device 200 and the processing of the evaluation output unit 152 will be discussed later. Figure 19 Let me explain in detail.

[0247] Figure 13 This diagram is used to further illustrate the function of the applicant device 300. Here, we use... Figure 13 This section explains the input and output of evaluations of recruiters. The evaluation receiving unit 151 also has the function of receiving evaluations of recruiters input by applicants into the applicant device 300. The evaluation output unit 152 also has the function of outputting information representing the evaluation of the recruiter to the applicant device 300. Applicants input their evaluations of recruiters into the applicant device 300 upon completion of the assigned work. The key points for applicants to evaluate recruiters are diverse.

[0248] For example, applicants will rate recruiters highly if they can communicate smoothly with them and complete tasks within a reasonable timeframe. Conversely, applicants will rate recruiters lowerly if there are numerous requests for additions, changes, or modifications to the work content; excessive time spent outside the scope of the work; late communication of instructions; or unilateral issuance of instructions regarding modifications without prior consultation.

[0249] The applicant device 300 accepts input of evaluations of the recruiter (step S16B). Therefore, the applicant device 300 functions as an evaluator device operated by the evaluator (applicant) when accepting the input evaluations.

[0250] The applicant device 300 sends the received evaluations to the evaluation receiving unit 151 of the shared server 100. The evaluation receiving unit 151 updates the evaluation input database 126 and the evaluation summary database 127 based on the received evaluations. This updates the information of the recruiter evaluation unit 126A in the evaluation input database 126 and the information of the recruiter evaluation summary unit 127A in the evaluation summary database 127.

[0251] Regarding the processing of step S16B performed by the applicant device 300 and the processing of the evaluation receiving unit 151, the following will be used... Figure 18 Let me explain in detail.

[0252] When the applicant device 300 receives an operation requesting an applicant to view evaluations of recruiters, it executes a view request process (step S17B). In this process, the recruiter device 200 sends a view request to the evaluation output unit 152 of the shared server 100. In response to the view request, the evaluation output unit 152 sends the evaluations of the recruiters (recruiter evaluation summaries) registered in the evaluation summary database 127 to the applicant device 300. The applicant device 300 then displays the received evaluations of the recruiters on the display 305 (step S18B).

[0253] The processing of steps S17B and S18B performed by the applicant device 300 and the processing of the evaluation output unit 152 will be discussed later. Figure 20 Let me explain in detail.

[0254] [Details of the handling of Case Registration Department 144 and Recruiter Device 200]

[0255] Figure 14 This is a diagram illustrating the process of registering recruitment cases into the recruitment case database 124. (Using...) Figure 14 More detailed explanation Figure 10 The functions of step S5 and the case registration department 144.

[0256] The recruiter registering a recruitment case first logs into the shared server 100 using the recruiter device 200. This establishes a logical communication path between the recruiter device 200 and the shared server 100, identified by the recruiter's member ID. Next, the recruiter uses the mouse and keyboard, or other operating units 206, to input the business and public information of the recruitment case into the recruiter device 200.

[0257] Information input through the operation unit 206 is communicated 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 for accepting operations for inputting service content and for inputting public information for specifying the object of the public service.

[0258] The business information for recruiting cases includes the case title, case details, projected working hours (persons / month), and projected period. Public information includes the level of disclosure. Depending on the recruiter's choice, the public information may sometimes include the ID of a company that is not publicly disclosed.

[0259] The recruiter device 200 accepts the input of business information and public information for recruitment cases and performs the registration of recruitment cases (step S5). During the registration of recruitment cases, the recruiter device 200 sends the business information and public information of the recruitment cases to the shared server 100.

[0260] The case registration department 144 of the shared server 100 obtains the recruiter's information (step S1441). Specifically, the case registration department 144 determines the company to which the recruiter belongs.

[0261] When a member logs into the shared server 100 using the recruiter device 200 or the applicant device 300, the shared server 100 stores the member ID used for login. When the shared server 100 receives certain information from the recruiter device 200 or the applicant device 300 in communication established through this member ID, it uses the member ID used for login to identify the member who sent this information.

[0262] Therefore, upon receiving recruitment business information and public information from the recruiter device 200, the case registration department 144 uses the member ID used for login to identify the recruiter operating the recruiter device 200. The case registration department 144 uses the identified member ID, member database 122, and enterprise database 121 to identify the member who is the recruiter and the enterprise to which the recruiter belongs.

[0263] Next, the case registration department 144 performs the process of registering the recruitment case in the recruitment case database 124 (step S1442). Specifically, after generating the case ID, the case registration department 144 registers the company information (company ID), the ID of the company set to be non-public, the public level, the case title, the planned working hours, the planned period, and the case content in the recruitment case database 124 corresponding to the generated case ID.

[0264] According to this implementation, recruiters can freely control the scope of recruitment announcements at levels such as "within the company," "within the community," and "unrestricted." As a result, it is possible to prevent recruitment announcements that recruiters do not want from being disclosed to specific companies.

[0265] According to this embodiment, companies designated as non-disclosure targets can be set separately from the disclosure level. Therefore, recruiters can set the disclosure scope by excluding a portion of companies that have community ties with the recruiter's company. As a result, it is possible to prevent business activities associated with specific companies within a community from being disclosed to that specific company.

[0266] Alternatively, a list of non-public member IDs can be set in the recruitment case database 124 instead of a list of non-public enterprise IDs, or a list of non-public member IDs can be set in the recruitment case database 124 in addition to the list of non-public enterprise IDs. This list of non-public member IDs is used to register member IDs that are prohibited from being publicly recruited. The recruiter device 200 can also process operations to specify members whose recruitment cases are prohibited from being publicly recruited and send the member IDs to the shared server 100. The shared server 100 may also choose not to provide recruitment cases corresponding to the member IDs listed in the non-public member ID list to the members whose member IDs are listed in the non-public member ID list. In this way, the recruiter device 200 can also process applications from either enterprises or members as objects of prohibited public business.

[0267] Figure 15 This is a diagram illustrating the process of retrieving recruitment cases from database 120. (Using...) Figure 15 More detailed explanation Figure 11 The processing of steps S6 and S7, and the function of the case extraction unit 145.

[0268] When the applicant device 300 receives an applicant's request to retrieve recruitment cases, it performs recruitment case retrieval processing (step S6). In the recruitment case retrieval processing, the applicant device 300 sends a retrieval request to the case extraction unit 145 of the shared server 100.

[0269] Upon receiving a search request, the case extraction unit 145 extracts cases that applicants are allowed to browse from the recruitment cases registered in the recruitment case database 124. Therefore, the case extraction unit 145 executes steps S1451 to S1454.

[0270] Steps S1451 and S1452 are processes for extracting cases that applicants are allowed to view based on the public scope set for the recruitment cases. In step S1451, the applicant's company and the company's community are determined. In step S1452, cases that can be made public are extracted.

[0271] Step S1453 is the process of extracting cases that applicants are allowed to browse based on their spare time from their side jobs. Step S1454 is the final process of extracting cases that match the applicants.

[0272] [Handling of cases based on publicly available information]

[0273] Step S1451 includes steps S1451A and S1451B.

[0274] In step S1451A, the applicant's company is determined based on the member ID used during login, company database 121, and member database 122.

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

[0276] Step S1452 includes steps S1452A and S1452B.

[0277] In step S1452A, recruitment cases that can be made public are extracted from the recruitment case database 124 based on the community and public level of the applicant's company.

[0278] In step S1452B, recruitment cases extracted in step S1452A are excluded from those of companies whose applicants are listed in the non-public company list. Here, the case extracted through step S1452B is referred to as Case X.

[0279] [Handling cases based on spare time from side hustles]

[0280] Step S1453 includes steps S1453A, S1453B, and S1453C.

[0281] In step S1453A, the available side hustle time T1 for the applicant is calculated. This available side hustle time is derived by calculating "side hustle cap time - total side hustle time". The side hustle cap time is determined by the applicant's company and is registered in the company database 121. The calculated available side hustle time is registered in the member database 122. The case extraction unit 145 may also calculate the available side hustle time for all members at regular intervals and register the calculated available side hustle time in the member database 122.

[0282] The total side hustle time is calculated based on the estimated and actual side hustle time registered in the Side Hustle Database 125, using the formula "Total Estimated Side Hustle Time + Total Actual Side Hustle Time". In other words, the total side hustle time includes not only the time already spent on side hustles but also the estimated time yet to be spent on them.

[0283] In step S1453B, the time T2 required to handle the business is calculated for each recruitment case. Time T2 is calculated based on the assumed working hours (persons / month) and assumed period registered in the recruitment case database 124. For example, the assumed working hours (month) can also be used as time T2. For example, for the recruitment case corresponding to case ID001, time T2 can also be set as 5 hours of time per month.

[0284] In step S1453C, recruitment cases that meet the condition "time T2 ≤ available time for side hustle T1" are extracted from the recruitment case database 124. Here, the case extracted through step S1453C is referred to as case Y.

[0285] [Case handling is based on the scope of public disclosure and the spare time available from side jobs]

[0286] Case extraction unit 145 extracts case X based on the public scope, extracts case Y based on the spare capacity of side jobs, and then extracts cases that are repeated in case X and case Y as matching cases for applicants (step S1454).

[0287] [Provide processing of the extracted cases]

[0288] Next, the case retrieval unit 145 sends matching case information 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).

[0289] Therefore, recruitment cases can be considered appropriate for applicants from two perspectives. First, applicants should be offered recruitment cases that they can manage within the time limit of their side hustle. This prevents applicants from becoming overworked. Second, recruitment cases should only be offered to applicants within the recruiter's desired public reach. This prevents the confidential information of the recruiter's company from being leaked to competing companies.

[0290] [Handling of side hustle plan registration time and side hustle performance time]

[0291] Figure 16 This is a diagram illustrating the process of recording the plans and achievements of a side hustle into database 120. (Using...) Figure 16 More detailed explanation Figure 12 The functions of step S14 and the performance acceptance department 149.

[0292] For example, when an applicant takes on a new side job, they input the planned time for the side job into the applicant device 300. During the period of engaging in the side job, they input the actual performance time of the side job into the applicant device 300 at any scheduled time. The applicant device 300 accepts the input of the planned time for the side job (step S14). The applicant device 300 sends the accepted planned time for the side job and the actual performance time to the performance acceptance unit 149 of the shared server 100.

[0293] The Performance Acceptance Department 149 accepts the applicant's side hustle plan time and side hustle performance time, and registers the accepted applicant's side hustle plan time and side hustle performance time in the side hustle database 125 (step S1511). Thus, the side hustle database 125 records the applicant's side hustle plan time and side hustle performance time for each month, categorized by case ID.

[0294] Typically, after applicants input their side hustle plan dates, they input the actual side hustle performance dates at the end of the month. Therefore, sometimes the side hustle database 125 contains cases where the side hustle plan dates were registered but the actual side hustle performance dates were not. For example, at the stage where applicants who took on side hustles input their side hustle plan dates, the plan dates were registered as data corresponding to that side hustle, but the actual side hustle performance dates were not registered.

[0295] Next, the Performance Acceptance Department 149 automatically calculates the estimated time for the sideline business for the current month (step S1512). The Performance Acceptance Department 149 calculates the estimated time for the sideline business based on the planned time and actual performance time. Specifically, the "estimated time for the sideline business," as already explained, is calculated using the formula "(work progress rate / progress rate) × planned time for the sideline business - actual performance time for the sideline business." Alternatively, the Performance Acceptance Department 149 can also calculate the "estimated time for the sideline business" using the formula "planned time for the sideline business - actual performance time for the sideline business." The Performance Acceptance Department 149 records the calculated estimated time for the sideline business in the sideline business database 125. For example... Figure 7 As shown in the side hustle database 125, the estimated time for each side hustle is registered by case ID.

[0296] [Processing of registration and evaluation results (evaluation of applicants)]

[0297] Figure 17 This is a diagram illustrating the process of registering applicant evaluations into database 120. (Using...) Figure 17 More detailed explanation Figure 12 The steps S16A and the functions of the evaluation and acceptance department 151.

[0298] Upon completion of the side job, the applicant submits a delivery and completion report to the recruiter, who then accepts the application. Afterwards, the recruiter operates the recruiter device 200, inputting evaluations of the applicant into the device. The recruiter device 200 accepts the input evaluations (step S16A). The recruiter device 200 sends the received evaluations to the evaluation receiving unit 151 of the shared server 100. The information sent from the recruiter device 200 to the shared server 100 includes the applicant's member ID and evaluation value (0~10).

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

[0300] If evaluation results for the applicants have already been registered in the evaluation input database 126, the evaluation receiving unit 151 calculates the average of the evaluation results for the applicants, including the values ​​of the evaluations received this time. The evaluation receiving unit 151 updates the evaluation results registered in the evaluation input database 126 using the calculated average. As a result, the evaluation input database 126 contains the average (evaluation results) of the evaluations of the applicants registered by the evaluator (recruiter). Therefore, the information of the applicant evaluation unit 126B is updated in the evaluation input database 126.

[0301] Next, the evaluation acceptance department 151 performs evaluation summary processing (step S1514A). In evaluation summary processing, the evaluation acceptance department 151 calculates the average evaluation results for the evaluated individuals (applicants) by company and department, and records the calculation results in the evaluation summary database 127. This updates the information of the applicant evaluation summary department 127B in the evaluation summary database 127.

[0302] For example, the evaluation receiving unit 151 uses the member ID used in the login process performed by the recruiter device 200 to execute step S16A to identify the evaluator (recruiter). Based on the evaluation information received in step S1513A, the enterprise database 121, and the member database 122, the evaluation receiving unit 151 determines 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. "Member ID" is an example of "identification information that the shared server 100 of the evaluation receiving unit 151 can use to identify the affiliation (company and department) of the person who accessed the shared server 100."

[0303] The evaluation processing department 151 accesses the evaluation summary database 127 to detect data rows arranged by the determined 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 processing department 151 updates the value of the applicant evaluation summary corresponding to the detected data row.

[0304] [Processing of Registration Evaluation Results (Evaluation of Recruiters)]

[0305] Figure 18 This is a diagram illustrating the process of recording evaluations of recruiters into a database. (Using...) Figure 18 To explain in more detail Figure 13 The functions of step S16B and the evaluation acceptance department 151.

[0306] As described above, upon completing the side job, the applicant delivers a completion report to the recruiter and accepts the recruiter's acceptance. Afterwards, the applicant operates the applicant device 300 to input their evaluation of the recruiter. The applicant device 300 accepts the input evaluation (step S16B). The applicant device 300 sends the received evaluation to the evaluation receiving unit 151 of the shared server 100. The information sent from the applicant device 300 to the shared server 100 includes the recruiter's member ID and evaluation value (0~10) as the evaluated party.

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

[0308] If evaluation results for the evaluated person (recruiter) are already registered in the evaluation input database 126, the evaluation receiving unit 151 calculates the average of the evaluation results for the evaluated person, including the values ​​of the evaluations received this time. The evaluation receiving unit 151 updates the evaluation results registered in the evaluation input database 126 using the calculated average. As a result, the evaluation input database 126 contains the average (evaluation result) of the evaluations of the evaluated person (recruiter) registered by the evaluator (applicant). Therefore, the information of the recruiter evaluation unit 126A is updated in the evaluation input database 126.

[0309] Next, the evaluation acceptance department 151 performs evaluation summary processing (step S1514B). In the evaluation summary processing, the evaluation acceptance department 151 calculates the average value of the evaluation results for the evaluated party (recruiter) by company and by department, and records the calculation results in the evaluation summary database 127. As a result, the information of the recruiter evaluation summary department 127A is updated in the evaluation summary database 127.

[0310] For example, the evaluation receiving unit 151 uses the member ID used in the login process performed by the applicant device 300 to execute step S16B to identify the evaluator (applicant). Based on the evaluation information received in step S1513B, the enterprise database 121, and the member database 122, the evaluation receiving unit 151 determines 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. "Member ID" is an example of "identification information including the identification information that the shared server 100 of the evaluation receiving unit 151 can use to identify the affiliation (company and department) of the person who accessed the shared server 100."

[0311] The evaluation processing department 151 accesses the evaluation summary database 127 to examine data rows arranged by the determined IDs (the member ID of the evaluated party, the ID of the company to which the evaluated party belongs, and the ID of the company to which the evaluator belongs). The evaluation processing department 151 updates the value of the recruiter evaluation summary corresponding to the detected data row.

[0312] For example, in Figure 9 In data group 1271, the following are arranged: member ID of the evaluated party = P1, ID of the company to which the evaluated party belongs = 00A, and ID of the company to which the evaluator belongs = 00B. If a member of the system department belonging to company B evaluates member P1, the evaluation is processed in step S1513B.

[0313] In this case, in step S1514B, the recruiter evaluation summary corresponding to "All" of data group 1271 and the recruiter evaluation summary corresponding to "System Department" reflect the evaluation received in step S1513B.

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

[0315] Figure 19 This diagram illustrates the process of displaying applicant reviews and member search results on display 205. (Using...) Figure 19 More detailed explanation Figure 10 Step S4A (processing of recruiter device 200) and the function of member retrieval unit 143, and Figure 12 The functions of steps S17A, S18A, and the evaluation output unit 152.

[0316] [Processing of summaries of applicant evaluations]

[0317] First, let me explain Figure 19 Each of the processes shown in steps S17A, S18A, S1521A, and S1522A.

[0318] When the recruiter device 200 receives an operation requesting the recruiter to view the evaluations of applicants, it executes a view request process (step S17A). In the view request process, the recruiter device 200 sends a view request to the evaluation output unit 152 of the shared server 100. In response to the view request, the evaluation output unit 152 selects from the evaluation summary database 127 the applicant evaluation summary for which the recruiter (view requester) has been granted viewing permission (step S1521A).

[0319] Recruiters who made browsing requests were granted access to applicant evaluation summaries for both the recruiter's company as a whole and the recruiter's department. Recruiters who made browsing requests were not granted access to any other evaluation summaries. The evaluation output unit 152 determined browsing permissions based on the recruiter's member ID, the company database 121, and the member database 122. "Member ID" is an example of "identification information that allows the shared server 100, including the evaluation processing unit 151, to identify the affiliation (company and department) of the person accessing the shared server 100 and their browsing permissions."

[0320] The evaluation output unit 152 selects the applicant evaluation summary corresponding to the browsing permission from the evaluation summary database 127. The evaluation output unit 152 sends data containing the selected applicant evaluation summary to the recruiter device 200 (step S1522A). In addition to the applicant evaluation summary, the sent data also includes the applicant's (evaluated) member ID, information about the applicant's company, and information about the applicant's department. Depending on the browsing request, the sent data may sometimes include applicant evaluation summaries corresponding to multiple applicants (evaluated).

[0321] Upon receiving the applicant evaluation summary, the recruiter device 200 displays the applicant evaluation summary along with information about the applicant's company and department on the display 205 (step S18A). When receiving applicant evaluation summaries corresponding to multiple applicants (evaluated individuals), the recruiter device 200 displays the applicant evaluation summaries as a single overview of the multiple applicants (evaluated individuals).

[0322] In this way, when the shared server 100 receives a browsing request in communication established through a member ID that can identify the company and department to which the recruiter belongs, it sends a summary of the applicant's evaluation information, as an example, to the recruiter device 200, which is the source of the recruitment request.

[0323] [Processing of Search Members (Applicants)]

[0324] Next, refer to Figure 19 To explain each process in steps S4A, S19A, and S1431A to S1433A.

[0325] When the recruiter device 200 receives a search request from a recruiter, it performs a member search process (step S4A) to retrieve information related to applicants. In this member search process, the recruiter device 200 sends a search request to the member search unit 143 of the shared server 100. The search request includes a benchmark value used to exclude members with low applicant ratings from the search. This benchmark value is determined, for example, based on the value of the applicant's evaluation summary.

[0326] Upon receiving the search request, the member search department 143 determines the company to which the recruiter who sent the search request belongs (step S1431A). Here, the company determined by step S1431A is referred to as "Company Xa".

[0327] Member retrieval unit 143 uses the member ID used when the recruiter device 200 logs into the shared server 100 to identify the recruiter operating the recruiter device 200. Member retrieval unit 143 uses enterprise database 121 and member database 122 to identify the enterprise Xa to which the recruiter belongs.

[0328] Next, the member retrieval unit 143 extracts members whose applicant evaluation summary values, targeting the determined company Xa as a whole, exceed the benchmark value from the evaluation summary database 127 (step S1432A). In other words, the member retrieval unit 143 extracts the search results after excluding members with low overall evaluations of company Xa.

[0329] Here, it should be noted that the member retrieval unit 143 determines whether the evaluation is low based on the applicant evaluation summary. That is, a member α who has permissions as both an applicant and a recruiter may act as an applicant or as a recruiter. Therefore, as such an applicant α, 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 but a low evaluation as an applicant. In this case, in step S1432A, member α may be excluded from the extraction list.

[0330] The shared server 100 can also be configured to accept benchmark value settings from the recruiter devices 200 of each company. This allows each company to exclude members with low ratings from search results using its own benchmark values.

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

[0332] As a result, recruiters can view the search results on display 205 after excluding members with low overall ratings for the recruiter's company. Therefore, recruiters can save the effort of visually excluding members with low overall company ratings when selecting a successor from applicants.

[0333] Furthermore, in this embodiment, even if a member has a low rating in a specific department of the recruiter's company, they will not be excluded from the search results if the company's overall rating is not low. However, the member search unit 143 may further exclude such members from the search results.

[0334] Figure 20 This diagram illustrates the process of displaying recruiter evaluations and member search results on monitor 305. (Using...) Figure 20 To explain in more detail Figure 10 Step S4B (processing of applicant device 300) and the functions of member retrieval unit 143, and Figure 13 The functions of steps S17B, S18B, and the evaluation output unit 152.

[0335] [Processing the output of recruiter evaluation summaries]

[0336] First, let me explain Figure 20 The processes shown in steps S17B, S18B, S1521B, and S1522B.

[0337] When the applicant device 300 receives an operation requesting an applicant to view evaluations of recruiters, it executes a view request process (step S17B). In this process, the applicant device 300 sends a view request to the evaluation output unit 152 of the shared server 100. In response to the view request, the evaluation output unit 152 selects a recruiter evaluation summary from the evaluation summary database 127 for which the applicant (view requester) has been granted viewing access (step S1521B).

[0338] Applicants who made browsing requests were granted access to recruiter evaluation summaries for both the applicant's company as a whole and the applicant's department. Applicants who made browsing requests were not granted access to any other evaluation summaries. The evaluation output unit 152 determined browsing permissions based on the applicant's member ID, the company database 121, and the member database 122. "Member ID" is an example of "identification information that allows the shared server 100, including the evaluation processing unit 151, to identify the affiliation (company and department) of the person accessing the shared server 100 and their browsing permissions."

[0339] The evaluation output unit 152 selects a recruiter evaluation summary corresponding to the browsing permission from the evaluation summary database 127. The evaluation output unit 152 then sends data containing the selected recruiter evaluation summary to the applicant device 300 (step S1522B). In addition to the recruiter evaluation summary, the sent data also includes the recruiter's (evaluated) member ID, information about the recruiter's company, and information about the recruiter's department. Depending on the browsing request, the sent data may sometimes include recruiter evaluation summaries corresponding to multiple recruiters (evaluated).

[0340] Upon receiving the recruiter evaluation summary, the applicant device 300 displays the recruiter evaluation summary along with information about the recruiter's company and department on the display 305 (step S18B). When receiving recruiter evaluation summaries corresponding to multiple recruiters (evaluated individuals), the applicant device 300 displays a summary of the multiple recruiters (evaluated individuals) as a single overview.

[0341] In this way, when the shared server 100 receives a browsing request in communication established through a member ID that can identify the company and department to which the applicant belongs, it sends a recruiter evaluation summary as an example of evaluation information to the recruiter device 300, which is the source of the browsing request.

[0342] [Processing of member (recruiter) searches]

[0343] Next, refer to Figure 20 To explain each process in steps S4B, S19B, and S1431B to S1433B.

[0344] When the applicant device 300 receives a search request from an applicant, it performs a member search process (step S4B) to retrieve information related to the recruiter. In this member search process, the applicant device 300 sends a search request to the member search unit 143 of the shared server 100. The search request includes a benchmark value used to exclude members with low recruiter ratings from the search. This benchmark value is determined, for example, based on the recruiter rating summary value.

[0345] Upon receiving the search request, the member search department 143 determines the company to which the applicant who sent the search request belongs (step S1431B). Here, the company determined by step S1431B is referred to as "Company Xb".

[0346] Membership search unit 143 uses the member ID used when applicant device 300 logs into shared server 100 to identify the applicant operating applicant device 300. Membership search unit 143 uses enterprise database 121 and member database 122 to identify the enterprise Xb to which the applicant belongs.

[0347] Next, the member retrieval unit 143 extracts members whose recruiter evaluation summary values, targeting the determined enterprise Xb as a whole, exceed the benchmark value from the evaluation summary database 127 (step S1432B). In other words, the member retrieval unit 143 extracts the search results after excluding members with low overall evaluations of enterprise Xb.

[0348] The shared server 100 can also be configured to accept benchmark value settings from the recruiter devices 200 of each company. This allows each company to exclude members with low ratings from search results using its own benchmark values.

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

[0350] As a result, applicants can view the search results on display 305 after excluding members with low overall ratings of the applicant's company. Therefore, applicants can save the effort of visually excluding members with low overall company ratings when selecting a successor from recruiters.

[0351] Furthermore, in this embodiment, even if a member has a low rating in a specific department of the applicant's company, they will not be excluded from the search results if the company's overall rating is not low. However, the member search unit 143 may further exclude such members from the search results.

[0352] [Browsing range of the evaluation summary database 127]

[0353] Figure 21 This is a diagram used to illustrate the browsable range of the evaluation summary database 127. Here, the evaluation summary database 127 is used as an example. Figure 9 The recruiter evaluation summary section 127A shown in the text is used as an example to illustrate the browsable range.

[0354] exist Figure 21 The recruiter evaluation summary section 127A shown includes evaluation summaries from companies B and C regarding member P1, who acted as a "recruiter." Member P1 belongs to company A. Company B's evaluation summary is categorized as "All," "Systems Department," and "Planning Department." Company C's evaluation summary is categorized as "All" and "Planning Department," etc. Members belonging to companies B and C browse the evaluation summaries for member P1 as "applicants."

[0355] Viewing permissions for the evaluation summary calculated based on the overall evaluation of Company B, such as... Figure 21 As shown in the "Browsable Scope" section, it is granted to all members belonging to Company B.

[0356] Access to the evaluation summary calculated based on the evaluation of Company B's System Department is granted to members of Company B's System Department, but not to members other than Company B's System Department. Access to the evaluation summary calculated based on the evaluation of Company B's Planning Department is granted to members of Company B's Planning Department, but not to members other than Company B's Planning Department.

[0357] Access to the evaluation summary calculated based on the overall evaluation of Company C is granted to all members belonging to Company C. Access to the evaluation summary calculated based on the evaluation of Company C's planning department is granted to members of Company C's planning department, but not to members other than Company C's planning department.

[0358] The above example, using recruiter evaluation summary section 127A, illustrates the browsable scope. In matching system 1, recruiter evaluation summary section 127B (see...) Figure 9 The browsing scope is determined by the same design philosophy as the recruiter evaluation summary section 127A.

[0359] If a visitor is set as a member of both the first department and the second department of Company X, the visitor's permissions for the overall review summary of Company X, the review summary of the first department of Company X, and the review summary of the second department of Company X are as follows: Figure 21As shown in Table 401. Here, when the applicant is equivalent to a "viewer," the viewer views the evaluation summary of the "recruiter." Conversely, when the recruiter is equivalent to a "viewer," the viewer views the evaluation summary of the "applicant."

[0360] Members belonging to the first department of Company X can view the overall evaluation summary of Company X and the evaluation summary of the first department of Company X, but cannot view the evaluation summary of the second department of Company X. Members belonging to the second department of Company X can view the overall evaluation summary of Company X and the evaluation summary of the second department of Company X, but cannot view the evaluation summary of the second department 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 department of Company X, or the evaluation summary of the second department of Company X.

[0361] The overall evaluation summary of Company X, the evaluation summary of Company X's first department, and the evaluation summary of 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 relationships between companies. Similarly, a member belonging to Company Y and acting as a recruiter can objectively evaluate applicants belonging to Company X without considering relationships between companies.

[0362] Furthermore, evaluations (evaluations of recruiters and applicants) conducted by members belonging to Company X are shared within Company X as recruiter evaluation summaries and applicant evaluation summaries. Therefore, evaluators are made aware that accumulating evaluations one by one yields useful information. This motivates evaluators to conduct accurate evaluations.

[0363] As a result, the accuracy of both recruiter evaluation summaries and applicant evaluation summaries has improved. Consequently, recruiter evaluation summaries can be used effectively and flexibly as reference data when selecting recruiting opportunities. Similarly, applicant evaluation summaries can be used effectively and flexibly as reference data when selecting candidates.

[0364] Furthermore, according to this embodiment, in the recruiter device 200, when member retrieval processing (step S4A) is performed, the retrieval results after excluding members with low ratings are provided to the recruiter (step S1432A). Similarly, in the applicant device 300, when member retrieval processing (step S4B) is performed, the retrieval results after excluding members with low ratings are provided to the recruiter (step S1432B). In other words, the matching system 1 has a filtering function that provides retrieval results after excluding members with low ratings.

[0365] Therefore, recruiters can prevent the erroneous hiring of low-rated members by selecting companies when deciding on recruitment services. Similarly, applicants can prevent the erroneous selection of services being recruited by low-rated members by selecting companies when choosing applicants from a large number of recruitment services. Furthermore, the shared server 100 can also perform filtering using evaluation summaries organized by department.

[0366] Alternatively, the recruiter device 200 can send an instruction signal to the shared server 100 instructing whether to use a filtering method that considers the evaluation summary for the entire enterprise or a filtering method that considers the evaluation summary for each department. In this case, the shared server 100 is configured to change the evaluation summary used for filtering based on the instruction signal.

[0367] [Example of setting the scope of disclosure based on disclosure level]

[0368] Figure 22 This is a diagram illustrating an example of setting the scope of disclosure based on the level of disclosure. Here, as... Figure 22 As shown, consider the case where companies A through E form a community relationship, and company F has no community relationship with any company. In this case, the scope of the recruitment case is as shown in Table 402, depending on the company to which the recruiter belongs and the level of disclosure set by the recruiter.

[0369] Figure 22 The disclosure levels "Level 1" to "Level 3" shown correspond to the previously explained levels of "Our Company," "Within the Community," and "All." Therefore, in Level 1, the recruiter's recruitment case is disclosed only to applicants within the same company as the recruiter. In Level 2, in addition to the scope of Level 1, the recruiter's recruitment case is disclosed to applicants belonging to companies with a community relationship to the recruiter's company. In Level 3, the recruiter's recruitment case is disclosed to applicants belonging to all companies, including the recruiter's company. However, if the recruiter specifies a company ID that is set to be non-public, regardless of the disclosure level set, companies corresponding to that company ID are excluded from the list of companies to which the information is disclosed. In this embodiment, "Level 1" corresponds to the level that "allows disclosure of business information to the first applicant but prohibits disclosure of business information to applicants who do not belong to the first group." "Level 2" corresponds to the level that "allows disclosure of business information to applicants who belong to the first group and to any group within the community groups that have formed a community relationship with the first group, but prohibits disclosure of business information to applicants who do not belong to the first group or any of the community groups." "Level 3" corresponds to the level that "allows disclosure of business information to applicants regardless of the group they belong to."

[0370] Here, as an example of multiple levels of openness, levels 1 through 3 as described above are illustrated. However, multiple levels of openness are not limited to these levels. For example, a community can be divided into multiple smaller communities, and each smaller community can be configured to publicly recruit services. More specifically, Figure 5 Community 02 is divided into a first sub-community and a second sub-community. Company C belongs to the first sub-community, while companies D and E belong to the second sub-community. In this case, it can also be set that the recruiter of company D can choose whether to set the scope of its recruitment business to the first sub-community or the second sub-community.

[0371] The shared server 100 can also handle operations that set the scope of disclosure differently for each recruitment case. For example, taking cases 001 to 003 out of multiple recruitment cases as examples, a specific example of setting the scope of disclosure differently for each recruitment case can be described.

[0372] For example, the public disclosure scope of recruitment case 001 can be limited to companies A and C belonging to the community identified using community ID=03. Alternatively, the public disclosure scope of recruitment case 002 can be limited to companies C, D, and E belonging to the community identified using community ID=02. Or, the public disclosure scope of case 003 can be limited to companies C, D, and E belonging to the community identified using community ID=02, and companies A and C belonging to the community identified using community ID=03.

[0373] Company A can also form communities different from those identified using community ID=01 or 02. For example, Figure 22 As shown by the dotted line, company A can form a community with company Z, identified by community ID = Z. For example, if the recruiter belongs to company A, the recruiter's recruitment case can be made public to applicants belonging to both company A and company Z. Such levels of public disclosure can also be... Figure 22 The example shown is a variation of "Level 3".

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

[0375] Here, levels 1 through 3 are shown as an example of multiple levels, but more levels can be set as multiple types of public levels. As an example of an interface for recruiters to set the scope of public access, a screen with checkboxes for setting the desired level from multiple types of levels can also be displayed on the user device 500.

[0376] [Example of the screen displayed when checking the status of a side hustle]

[0377] Figure 23 This is a diagram showing the screen displayed on the manager's (the applicant's superior) applicant device 300 when the manager (the applicant's supervisor) checks the subordinate's side job status. Figure 23 An example is shown where the side-work status of a manager's subordinates 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.

[0378] Here, the manager is, for example, the head of the sales department of company C. The side-work status of the employees belonging to the sales department is displayed on monitor 305. The manager can confirm the side-work status of the employees belonging to the sales department by using the keyboard 306A or mouse 306B to specify any of the labels 307A, 307B, 307C, etc. Therefore, the manager can manage the subordinates' working hours, preventing them from becoming overworked. Furthermore, the progress rate can also be displayed on the screen.

[0379] [Example of a screen displayed when changing browsing restriction settings]

[0380] Figure 24 This diagram shows the screen displayed on the applicant's device 300 when the administrator changes the browsing restriction settings. Here, it is assumed that the administrator operating the applicant's device 300 (user device 500) belongs to company D. Figure 24 As shown, display 305 shows a list of business cases being recruited by company D. Display 305 also shows that company D has formed a community relationship with companies C and E.

[0381] The case overview includes information related to each case, such as "Case ID," "Recruiter's Company ID," "Recruiter's Company Name," and "Case Title." Figure 24 The document lists several business cases, including those of Company C and Company F. The business case overview also includes a settings area where administrators can set "viewing restrictions" for each business case.

[0382] Administrators can use mouse 306B to move cursor 308 to a designated area, where they can toggle browsing restrictions between "On" and "Off". "Off" corresponds to no browsing restrictions, and "On" corresponds to browsing restrictions. The "On" setting is an example of restrictive information used to limit browsing. The default setting for the designated area is "Off". When the browsing restriction setting is switched from "Off" to "On", all employees belonging to Company D cannot view the business cases corresponding to "On".

[0383] exist Figure 24 The example shown illustrates an instance where the browsing restriction setting for business cases of Company C corresponding to "Case ID=011" is enabled. By switching the browsing restriction setting for business cases of Company C corresponding to "Case ID=011" from disabled to enabled, all employees of Company D are unable to browse business cases of Company C corresponding to "Case ID=011".

[0384] Company C and Company D have a community relationship, therefore it can be understood that Company C and Company D are not in competition. From this perspective, Company C would readily accept Company D employees browsing its business cases and applying for them. However, depending on the content of the business cases or the company's situation, Company D may sometimes object to its employees taking on Company C's business cases.

[0385] For example, if an employee of Company D is handling a specific case for Company C, potentially leading to the leakage of Company D's know-how to Company C, Company D should want to avoid having its employees apply for such a specific case. Alternatively, if recent industry evaluations of Company C are poor, Company D might want to avoid having its employees apply for Company C's cases in the near future.

[0386] Therefore, the matching system 1 includes a function allowing applicants to set viewing restrictions for specific business cases. Applicants can set these restrictions. Consequently, all employees of the applicant's company will be unable to view the business cases for which the restrictions have been set.

[0387] Information regarding which of several business cases has been restricted is not communicated to recruiters. Therefore, recruiters understand it as a lack of applications from applicants belonging to a specific company, but do not perceive it as a restriction on access to business cases. Thus, for example, even if company D has imposed restrictions on recruitment cases for company C, this will not cause problems with the community relationship between company C and company D.

[0388] Furthermore, an example of setting browsing restrictions on a per-case basis has been described here. However, the system can also be configured to set browsing restrictions for both the company and the case type (business cases, etc.). In this case, it can also be configured such that if a case added after the browsing restrictions have been set meets the conditions of the already set browsing restrictions, the added case will also be immediately subject to browsing restrictions. Additionally, the scope of the browsing restrictions can be configured to restrict not only the company as a whole but also specific departments specified when the browsing restrictions were set. Thus, while a user cannot display cases to, for example, a research department that handles confidential information, they can display cases to other departments such as general affairs.

[0389] [Time Sequence Diagram]

[0390] Figure 25 This is a sequence diagram illustrating the setting of restriction information. Here, we use companies C~E, which form a community relationship, as an example to explain the process of setting browsing information for business cases.

[0391] Company C is a user (recruiter) providing business cases. Companies D and E are users (applicants) authorized by Company C to view business cases. 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. Additionally, Company C's user device 500 is an example of a second user device operated by a second user.

[0392] First, the user device 500 of enterprise C sets up a business case and public information according to the user's operation (step S101). Next, the user device 500 of enterprise C sends the business case and public information to the shared server 100 according to the user's operation (step S102). In addition, the user can set up more than two business cases in step S101, or set up one business case.

[0393] Next, the shared server 100 registers the received business cases in the recruitment case database 124 (step S103). Then, the shared server 100 sets the scope of disclosure based on the received public information (step S104). Here, the scope of disclosure for the business cases is limited to "community" based on the public information. In this case, the business cases are only disclosed to companies D and E. Thus, the shared server 100 sets the scope of disclosure for the business cases provided by the second user (a user belonging to company C) based on the public information indicating the scope of disclosure for the business cases. Here, steps S103 and S104 are an example of a setting unit that accesses the database where business cases are registered and sets the scope of disclosure for business cases disclosed to the first group to which the first user belongs based on the public information indicating the scope of disclosure for the business cases.

[0394] Shared server 100 discloses business cases to Enterprise D and Enterprise E according to the set disclosure scope (step S105). Enterprise E's user device 500 obtains the business cases based on user operations (step S106). Enterprise E's user device 500 displays the obtained business cases (step S107). Enterprise D's user device 500 obtains the business cases (step S108). Enterprise D's user device 500 displays the obtained business cases (step S109).

[0395] Next, the user device 500 of enterprise D registers with the shared server 100 in administrator mode according to the user's operation (step S110). Then, the user device 500 of enterprise D sets restriction information according to the user's operation (step S111). For example, such as... Figure 24 As shown, the user selects the business case for which browsing restrictions are desired and switches the "off" to "on" setting for the area. Step S111 is an example of a processing department handling user operations that input restriction information.

[0396] Next, the user device 500 of enterprise D sends restriction information to the shared server 100 according to the user's operation (step S112). Here, restriction information is sent to the shared server 100 for each business case. In addition, step S112 is an example of a sending unit that sends restriction information to the computing device when the receiving unit has accepted the user's operation.

[0397] 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 shared 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 shared server 100. That is, the user device 500 is configured to selectively send restriction information for the first case and restriction information for the second case to the shared server 100 based on user operations.

[0398] Next, the sharing server 100 receives restriction information (step S113). Step S113 is an example of a receiving unit receiving 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 the restriction information used to restrict users of enterprise D from browsing the business case in the recruitment case database 124.

[0399] Step S114 is an example of a restriction section that limits the disclosure of business cases to the first group based on restriction information, regardless of the scope of disclosure set based on publicly available information. Furthermore, in Figure 15In step S1452, if the applicant is a user of Enterprise D, business cases with restricted information are excluded from the publicly available business cases.

[0400] Next, the shared server 100 discloses the business case only to users of enterprise E (step S115). As a result, the business case is no longer disclosed to users of enterprise D. In this way, regardless of the scope of disclosure set based on the disclosed information, the shared server 100 restricts the disclosure of business cases provided by the second user (a user belonging to enterprise C) to the first group (enterprise D) based on the restriction information. The restriction information is an example of 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 disclosed information.

[0401] [Case details]

[0402] Figure 26 This is a diagram showing details of cases contained in the recruitment case database 124. The case details include recruitment points. For example... Figure 26 As shown, the case details are registered in the recruitment case database 124 by case ID.

[0403] The case details include the case name, case details, the registrant, and the project of the company that registered the case. The case name contains the title of the recruitment case. The case details include an article describing the content of the recruitment case. This article may sometimes include the skills, experience, and qualifications required of the applicant. The registrant is the person who registered the case, i.e., the recruiter. The company that registered the case is the enterprise to which the registrant belongs.

[0404] The case details are made public to users (applicants) who have permission to disclose the case. Company terminology is sometimes used in the articles included in the case details. Such company terminology is registered as "index information" in the recruitment case database 124 in association with company terminology in the company terminology database 136 described later.

[0405] If already used Figure 1 As explained, user device 500 displays company terminology in a different way than other terms. Thus, the user understands that this is company terminology. Furthermore, user device 500 displays the meaning of the company terminology based on the user's actions (e.g., clicking on the company terminology section).

[0406] Applicants research case details and decide which cases they want to apply for from a large pool of cases. Before making a final application, applicants may interview the recruiter for the case, as needed. Additionally, the recruiter may select specific individuals from the applicants as temporary contractors and interview these temporary contractors before signing a business contract. After signing a business contract with an applicant, the recruiter may conduct further interviews with the applicant (contractor) regarding the business details, depending on the progress of the business.

[0407] User device 500 can also provide recruiters and applicants with an environment for conducting these interviews via web conferencing. When an article containing company terminology is displayed on the monitor during a web conferencing session, user device 500 can also... Figure 1 The format shown displays company terminology.

[0408] [Other Databases]

[0409] Below, besides Figure 2 In addition to the various databases 121 to 127 shown, other databases used in this embodiment are also described.

[0410] Figure 27 This is a diagram illustrating an example from the profile database 129. (As shown...) Figure 27 As shown, in profile database 129, member (user) profile information is registered by member ID. Some of the profile information may overlap with information registered in member database 122. Profile information includes the member's name, age, and gender. Profile information also includes affiliation information that identifies the member's company and department. Affiliation information is an example of group information used to identify either a company or a department within a company.

[0411] Furthermore, the profile information includes the member's capabilities. These capabilities are categorized by skills, experience, and qualifications.

[0412] Figure 28 This is a diagram illustrating an example of the company's internal terminology database 137. (See diagram for example.) Figure 28 As shown, internal terminology information is registered in the internal terminology database 137 by company ID. The shared server 100 determines the internal terminology by company by referring to the internal terminology database 137.

[0413] Company terminology information includes affiliation information that identifies a member's affiliation (company and department). Affiliation information is an example of group information used to identify either a company or a department within a company. Affiliation information can also be described as information about the company and department that has popularized the company terminology used by the registered entity.

[0414] The information on internal company terminology also includes the “name,” “pronunciation,” and “meaning” of the term being registered. For example, in the case of the internal company term “DX,” “DX” is registered in the “name,” “ディーエックス” is registered in the “pronunciation,” and “the meaning” is registered as “creating a certain new value regardless of whether digital technology is used.”

[0415] Another example of company terminology is "application development." "Application development" is generally understood to refer to developing applications for use in electronic devices such as smartphones. However, in a department within a company that deals in electronic components, "application development" might mean "expanding the uses of components." In this case, the term "application development" and its meaning (expanding the uses of components) are registered in the company terminology database 137.

[0416] [Description of the processing procedures related to indexing functionality]

[0417] Next, refer to Figures 29-32 This will explain the various processing procedures related to indexing functionality. Figure 29 This is a flowchart illustrating the processing procedures related to the indexing function of matching system 1.

[0418] exist Figure 29 In the flowchart shown, firstly, the shared server 100 registers company terminology in the company terminology database 137 (step Sw1). In step Sw1, the shared server 100 functions as the company terminology registration department. Next, the shared server 100 registers recruitment cases in the recruitment case database 124 (step Sw2). In step Sw2, the shared server 100 functions as the case registration department. When registering recruitment cases in the recruitment case database 124, the case registration department adds an index to the company terminology contained in the recruitment case information.

[0419] Next, the shared server 100 displays the indexed case information on the user device 500 (step Sw3). For example, if company terminology is used in the article describing the case details, the underlined company terminology is displayed on the user device 500. Alternatively, instead of underlining the company terminology, the company terminology may be displayed in a different color on the user device 500 screen 552, or in addition to underlining the company terminology, the company terminology may also be displayed in a different color on the user device 500 screen 552. In step Sw3, the shared server 100 functions as a display unit.

[0420] Figure 30This is a flowchart illustrating the processing flow of the company's internal terminology registration department (Sw1). First, the company's manager uses the company's system to compile a list of internal terms (step Sw11). That is, the manager creates something like a set of internal terms. Next, the manager downloads a registration template from the shared server 100 (step Sw12). Then, the manager enters the necessary information into the template (step Sw13). The necessary information includes the internal terminology, its meaning, and its definition.

[0421] Next, the company's representative accesses the shared 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 the template along with the profile information to the matching system 1 (step Sw15). The shared server 100 retrieves the profile information and the template. Based on the retrieved profile information and template, the shared server 100 generates internal company terminology information and registers the generated internal company terminology information in the internal company terminology database 137 (step Sw16). Thus, the internal company terminology and its meaning are registered in the internal company terminology database 137. Furthermore, the internal company terminology and its meaning are registered in the internal company terminology database 137 by company.

[0422] Steps Sw11 to Sw16 are performed for each company. As a result, company terminology information is registered in the company terminology database 137 for each company. Furthermore, the shared server 100 can also register company terminology from external files such as CSV (Comma Separated Value) files into the company terminology database 137.

[0423] Figure 31 This is a flowchart illustrating the processing flow of the case registration department (Sw2). First, a recruiter who wants to register a recruitment case in the system accesses the profile database 129 to obtain their company information (step Sw21). Next, the recruiter inputs case information into the user device 500 (step Sw22). The case information includes various information such as the case details registered in the recruitment case database 124. The recruiter may use company terminology commonly used in their company to input the details of the case details.

[0424] Next, the shared server 100 automatically retrieves company terminology contained in the input case information (step Sw23). At this time, the shared server 100 adds an index to the retrieved company terminology to associate it with company terminology information registered in the company terminology database 137. Then, the shared server 100 registers the case information entered by the recruiter in the recruitment case database 124 (step Sw24). Thus, by mapping company terminology to their meanings, the case information is registered in the recruitment case database 124.

[0425] Figure 32 This is a flowchart illustrating the process of displaying the meaning of company terminology on a screen based on the applicant's actions. Here, the process is explained to provide applicants with matching cases that are relevant to the scope of the recruitment case and the applicant's skills, and to teach the applicants the meaning of company terminology as needed.

[0426] First, the shared server 100 receives a search request for recruitment cases submitted by applicants (step Sw 101). Next, the shared server 100 determines the applicant's affiliation (step Sw 102). Details of this process have been described as step S1451.

[0427] Next, the shared server 100 extracts cases that can be made public (step Sw 103). Details of this process have been described as step S1452. Next, the shared server 100 extracts cases that can be handled by the assistant's skills (step Sw 104). Details of this process have been described as step S1453. Alternatively, step Sw 104 can be removed from this flowchart. That is, the shared server 100 can also extract cases that match the applicants regardless of the assistant's skills.

[0428] Next, the sharing server 100 retrieves matching cases (step Sw 105). Details of this process have been described as step S1454. Next, the sharing server 100 sends the matching cases (step Sw 106). Details of this process have been described as step S1455. In this way, the sharing server 100 displays the matching cases on the applicant device 300 by sending the matching cases to the applicant device 300.

[0429] Next, the shared server 100 detects click operations for company terms corresponding to the registered index (step Sw 107). Then, the shared server 100, referring to the company terminology database 137, sends the meanings of the company terms to the applicant device 300 (step Sw 108). Next, the applicant device 300 displays the meanings of the company terms on the display 305 (step Sw 109). Thus, for example, the meanings are displayed on the display 305. Figure 1 The screen shown is 552. In this way, the shared server 100 displays the meaning of company terminology on the applicant device 300 by sending the meaning of company terminology to the applicant device 300.

[0430] As explained above, according to this embodiment, a matching system 1 that functions as a crowdsourcing platform can be provided. To find more suitable talent using crowdsourcing, it is desirable to further expand the scope of crowdsourcing, rather than limiting it to a specific enterprise or a small number of enterprises. In this case, it is necessary to consider the interests of the recruiter who is recruiting the business and the applicant who is applying for the recruitment. In this embodiment, the sharing server 100 communicates with the applicant device 300 operated by the applicant via the communication interface 104. The sharing server 100 registers the business information for recruiting business partners and the public information indicating the scope of disclosure of the business information in the database (step S1442). Based on the public information, the sharing server 100 determines the business information registered in the database 120 that is allowed to be disclosed to the applicant (step S1452). The business information includes detailed information related to the content of the business (case details (recruitment guidelines)). The shared server 100 will display the business information that can be disclosed to applicants and the meaning of the terms contained in the detailed information (including internal terms used within the company) on the applicant device 300 (steps Sw3, Sw106, Sw109).

[0431] Therefore, according to this embodiment, it is possible to select suitable applicants who take into account the interests of the recruiter and the applicant. Furthermore, according to this embodiment, it is possible to prevent applicants from misunderstanding the content of business information due to unfamiliar terminology or terminology used with meanings different from the usual usage.

[0432] Furthermore, according to this embodiment, users can reduce the effort required to supplement internal company terminology when exchanging case-related information with users outside the company. Moreover, the shared server 100 can automatically add an index to the internal company terminology included in the case information. Therefore, users do not need to manually add an index to the internal company terminology. Furthermore, the shared server 100 has the function of registering internal company terminology in the internal company terminology database 137. Therefore, users do not need to manually register internal company terminology in the internal company terminology database 137. Furthermore, users can recognize that other companies may not understand internal company terminology, thus enabling them to understand cultural differences with other companies.

[0433] In this embodiment, "company terminology" used by enterprises is cited as an example of "internal language" that is prevalent in the user's group. However, the previously described implementation method may also be applied to terms similar to company terminology used in non-profit organizations, communities, and their units (departments, employees, etc.) in addition to "company terminology".

[0434] In this implementation, "groups of enterprises" and "groups of departments within the same enterprise" are examples of "groups." Freelancers and other applicants who are not affiliated with an enterprise can also constitute a "group." Multiple enterprises can also constitute a "group of enterprises."

[0435] In this implementation, "enterprises that form community relationships" is an example of "community groups".

[0436] In this embodiment, the information of "non-public objects" included in the public information is an example of "information that can identify the object of prohibition from disclosing business information".

[0437] Communication from the applicant device 300, which functions as the approver and acts as the manager, to the approval department 147 to send approval information. Figure 11 S9) is performed in a logical communication path that uses the member ID of the approver for identification. “The approval department 147 receives approval information in such a communication path” is an example of “receiving an approval notification in communication accompanied by the identification information of the approver of the first applicant”.

[0438] 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.”

[0439] In this embodiment, the "recruiter device 200A" operated by the 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".

[0440] In this embodiment, the "recruiter device 200B" operated by the 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".

[0441] exist Figure 21 In this example, the Systems Department and the Planning Department are shown as departments of Company A. In this embodiment, "one of the Systems Department and the Planning Department" is an example of a "first segmented group" included in the first group, and the other is an example of a "second segmented group" included in the first group.

[0442] The shared server 100 extracts business information from the list in the recruitment case database 124, based on the projected working hours registered in the recruitment case database 124, the maximum side hustle time registered in the enterprise database 121, the actual side hustle time registered in the side hustle database 125, and the estimated side hustle time registered in the side hustle database 125, to determine if the applicant's working hours do not exceed the maximum time limit. Specifically, for example, if the applicant is engaged in multiple side hustles, the shared server 100 calculates the total actual side hustle time corresponding to each side hustle, and calculates the total estimated side hustle time corresponding to each side hustle, to determine the total estimated side hustle time. The shared server 100 adds the calculated total actual side hustle time to the total estimated side hustle time to determine the total side hustle time. The shared server 100 calculates the applicant's available side hustle time by subtracting the total side hustle time from the applicant's maximum side hustle time. Shared server 100 retrieves cases from the recruitment case database 124 that can be handled within the calculated available side-work time. At this time, shared server 100 calculates the time required to handle each recruitment case based on the assumed working hours in recruitment case database 124, and retrieves recruitment cases within the available side-work time range. Here, "side-work cap time" is an example of "the cap time as the cap of the applicant's working time," "side-work performance time" is an example of "performance time as the time the applicant has actually worked," and "side-work estimated time" is an example of "estimated time as the applicant's expected working time." The cap time can also be a time that sets a cap not only on the side-work but also on the total time of the main job and side-work time. The first cap time may also not be the side-work cap time, but rather the time that sets the cap on all business activities combined with the main job as the target. The first performance time and the first estimated time can be not only the side-work time but also the total time of all business activities combined with the main job.

[0443] Recruiter Device 200 and Respondent Device 300 can also be equipped with more than just these features. Figure 2 The processor, memory, communication interface, and input / output interface shown are all included, as well as a thin client system utilizing VDI (Virtual Desktop Infrastructure). A VDI-based thin client system is a system that transmits a desktop environment located on a server to a remote terminal. The recruiter device 200, the applicant device 300, and the shared server 100 do not necessarily have to be separate devices. When using the thin client system described above, the functions of the recruiter device 200, the applicant device 300, and the shared server 100 can be provided on the same integrated server.

[0444] Database120 is not limited to relational databases; it can also utilize object-oriented databases, NoSQL databases, and so on.

[0445] Shared server 100 is an example of a computing device. A computing device can also consist of servers (on-premises servers, cloud servers, etc.), serverless systems, etc. Here, an on-premises server refers to a server located within and managed by the company. A cloud server refers to a server provided by another operator via a network (a rented server). A serverless system refers to a system that is unaware of the existence of a server and can utilize computing and storage functions only when needed. Computing devices include servers and serverless systems. Servers include on-premises servers and cloud servers.

[0446] <Variation Example 1>

[0447] Next, refer to Figure 33 Explain the variation of Example 1. Figure 33 This is a flowchart relating to the processing of restriction information performed by the shared server 100 as a variant example 1. Regarding the setting of restriction information, [the flowchart uses...]. Figure 24 as well as Figure 25 An example of setting restriction information for each business case is introduced.

[0448] However, when there are a large number of business cases for which browsing restrictions are desired, setting restriction information for each business case would increase the burden on the user. Furthermore, it is difficult for the user to reliably set restriction information for all business cases that should be restricted. Therefore, in Variation 1, an example is described whereby the user specifies the company providing the business cases for which browsing restrictions are desired, or the industry type of that company (e.g., the electronics components industry), to set restriction information for business cases corresponding to the specified company or industry type.

[0449] In addition, to implement Variation 1, the user of Matching System 1, besides registering the enterprise ID used to identify the enterprise, also registers the industry type ID used to identify the industry type of the enterprise in the enterprise database 121. Figure 3 ) and recruitment case database 124 ( Figure 5 In the databases of )

[0450] First, users belonging to the applicant-side companies register with the shared server 100 in administrator mode, and then input the name of the company or the industry type of the company for which they want to set restriction information into the user device 500. The input company name is an example of user-specified information and company-specified information. The input industry type is an example of industry type specified information.

[0451] For example, consider a scenario where a user belonging to company D sets restriction information based on 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 (the first user) inputs the company name of company C into user device 500. The "company name of company C" input into user device 500 is an example of user-specified information. Thus, the user-specified information includes information for specifying the second group.

[0452] Furthermore, as a group wishing to set restricted information, the user can specify not only for-profit organizations such as businesses, but also non-profit organizations and communities utilizing Matching System 1. Alternatively, if there are members who are not part of an organization but are using Matching System 1 as individuals, the user can also input the name of such individual members into the user device 500. In other words, the object specified by the user can be any of for-profit organizations, non-profit organizations, or individuals.

[0453] User device 500 sends information related to the name or industry type of the entered enterprise as restriction information to shared server 100. Shared server 100 accepts the setting of restriction information from user device 500 (step S120).

[0454] Next, the shared server 100 refers to the recruitment case database 124 and retrieves the business cases that match the restriction information from the user-disclosed business cases among multiple business cases (step S121). The business case that matches the restriction information is the business case registered with the enterprise ID corresponding to the enterprise name accepted in step S121. Alternatively, the business case that matches the restriction information is the business case registered with the industry type ID corresponding to the industry type name accepted in step S121.

[0455] Next, the shared server 100 sets "restriction information" in the recruitment case database 124 to exclude business cases matched in the search in step S121 from the public scope (step S122).

[0456] Next, after registering with the shared server 100 in normal mode, the user belonging to the applicant company requests to view the service case from the shared server 100. Then, the shared server 100 accepts the service case viewing request from the user via the user device 500 (step S123).

[0457] Next, the shared server 100 sends the business cases that are publicly disclosed, excluding those excluded by restriction information, to the user device 500 (step S124), and ends the processing based on this flowchart. In the user device 500, the business cases that are publicly disclosed, excluding those excluded by restriction information, are displayed.

[0458] Furthermore, an example of setting restriction information using company name or industry type name as keywords is illustrated here. However, the system can also be configured so that users can combine multiple keywords to specify business cases for which they want to set restriction information. For example, matching system 1 could also allow users to specify the industry type name for which they want to set restriction information using the first keyword, and specify companies (e.g., venture capital firms) for which they want to exclude from the restriction information settings using the second keyword.

[0459] Additionally, Matching System 1 can also handle the following user operations: specifying the industry type of the enterprise for which restriction information is to be set, and specifying the exclusion of a subset of enterprises related to that industry type from the restriction information settings. Furthermore, industry type is merely one way to categorize restrictions. Restriction information can also be composed of industry type, enterprise name, department name (e.g., Intellectual Property Department), or alternatively, enterprise name, department name (e.g., Intellectual Property Department) can be used instead of industry type.

[0460] <Variation Example 2>

[0461] Next, refer to Figures 34-36 Explain Variation Example 2. In Variation Example 2, we illustrate the reverse offer function by which a recruiter can urge a person selected from multiple members to be recruited into the recruitment business.

[0462] [Background for proposing the reverse offer function]

[0463] In crowdsourcing, recruiters typically post job openings and wait for responses from those interested in the content of the job. However, in this recruitment method, it can take time until a response is received from applicants. Furthermore, it's unclear whether anyone with the skills the recruiter is looking for will apply.

[0464] Therefore, recruiters can consider searching for members and specifying suitable members (reverse offer). However, when recruiters only know the member ID and name, it is difficult for them to specify the truly desired applicants. Furthermore, to prevent confidential information from being leaked to competitors, member information from competitors must be excluded from the search results.

[0465] In Variation 2, based on this background, search results containing detailed resume information of members are provided to recruiters who have conducted member searches. Furthermore, in Variation 2, member information of companies that are competitors of the recruiter is excluded from the search results. Variation 2 will now be described in detail using accompanying drawings.

[0466] Figure 34 This is a diagram used to illustrate the functions of the shared server 100, recruiter device 200, and applicant device 300 in relation to Variation 2.

[0467] like Figure 34 As shown, in addition to the member retrieval unit 143, the shared server 100 also includes a reverse offer delegation unit 161, a reverse offer approval delegation unit 162, and a reverse offer delegation acceptance notification unit 163. These various functions are implemented through the processor 101, memory 102, storage device 103, and communication interface 104 provided by the shared server 100.

[0468] As already explained, the member retrieval unit 143 has the function of retrieving members of the matching system 1. In particular, in variant 2, the member retrieval unit 143 has the function of providing the searcher with detailed resume information of the members. When the recruiter device 200 accepts the search operation of the recruiter, it performs member retrieval processing (step S21). In particular, in step S21, the recruiter device 200 accepts the search operation for the recruiter to make a reverse offer. The member retrieval unit 143 provides the recruiter device 200 with information of members registered in the member database 122. The information of the members provided includes detailed resume information of the members. However, the member retrieval unit 143 excludes member information of companies that are competitors of the recruiter's company from the search results.

[0469] The recruiter device 200 receives member information (search results) from the member retrieval unit 143 and displays the member information as search results on the display 205 (step S22). Afterwards, the recruiter device 200 accepts the recruiter's operation of selecting applicants from the search results. That is, the recruiter selects members to make a reverse offer based on the search results and implements the reverse offer by operating the recruiter device 200 (step S23). The recruiter device 200 sends the member ID of the member designated as the object of the reverse offer to the shared server 100.

[0470] The reverse offer delegation unit 161 receives the member ID of the member designated as the target of the reverse offer from the recruiter device 200. The reverse offer delegation unit 161 identifies the member corresponding to the received member ID. The reverse offer delegation unit 161 notifies the applicant device 300 of the member designated as the target of the reverse offer that the delegation of the reverse offer has been received. This notification may also include information about the recruitment case designated as the target of the reverse offer. The member designated as the target of the reverse offer receives the delegation of the reverse offer through the applicant device 300. Here, the received "delegation" is an example of "information urging the applicant to apply." The member designated as the target of the reverse offer determines whether to accept the delegation of the reverse offer. The member designated as the target of the reverse offer can use the applicant device 300 to accept or reject the delegation of the reverse offer. The applicant device 300, for example, accepts the delegation of the reverse offer (step S24). The applicant device 300, which has accepted the reverse offer, sends the application information to the reverse offer approval department 162.

[0471] The reverse offer approval delegation unit 162 sends the applicant's application information to the applicant's superior. Based on the relationship between the applicant's member ID registered in the member database 122 and the superior's member ID, the reverse offer approval delegation unit 162 determines the member ID of the superior who is the applicant's manager. The applicant's superior confirms the application information in their own applicant device 300 and approves the application (step S25).

[0472] The reverse offer acceptance notification unit 163 receives approval information from the applicant's superior. The reverse offer acceptance notification unit 163 accepts the applicant's application upon receiving the approval information. The reverse offer acceptance notification unit 163 notifies the recruiter device 200 that the application from the member to whom the reverse offer was made 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 the information used to notify the recruiter that the reverse offer has been accepted on the display 205.

[0473] Figure 35 This is a diagram illustrating an example of member database 122A related to variant example 2. Figure 35 In the member database 122A shown, with Figure 4 Compared to the member database 122 shown, resume information and resume disclosure information indicating whether the resume is made public have been added.

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

[0475] Members use the applicant device 300 to set their resumes to be publicly available. If the resumes are set to be publicly available, the member's resume information is provided to the searcher. If the resumes are set to be unavailable, the member's resume information is not provided to the searcher. The shared server 100 registers the resumes' public availability information in the member database 122A based on the settings selected by each member. Thus, the shared server 100 receives input from each of the multiple members indicating whether they permit their resume information to be included in the search results.

[0476] Here, an example is given of determining whether to allow the disclosure of a member's resume information based on the settings for publicly available resume information. However, the sharing server 100 can also handle the setting operation for whether to allow disclosure based on the type of resume information. Thus, for example, a member can set their achievements and qualifications to be publicly available, while setting their SPI information to be private. Or, if the resume information includes age, the member can set the age to be private and set other resume information to be publicly available. In this case, the sharing server 100 registers multiple resume information for each of the multiple registrants (members) into the member database 122A. The sharing server 100 accepts input from each of the multiple registrants for setting the scope of disclosure of the multiple resume information as a search result.

[0477] Figure 36 This is a flowchart illustrating the processing procedure for the reverse offer member retrieval process related to Variation 2. The processing based on this flowchart is performed by the shared server 100.

[0478] First, the shared server 100 accepts a search request from a searcher to find a suitable member for a recruitment case (step S211). Here, the searcher is a recruiter with a recruitment case. The recruiter uses its own recruiter device 200 to search for members who possess the appropriate skills for the recruitment case in order to make a reverse offer. In step S211, the search request from the recruiter is accepted in the shared server 100. The search request may also include the searcher's member ID and the case ID of the recruitment case.

[0479] Next, the shared server 100 determines the company to which the searcher belongs from the member database 122A and the enterprise database 121 (step S212). Next, the shared server 100 determines the community to which the searcher belongs from the community database 123 (step S213).

[0480] Next, the shared server 100 determines the public level and non-public enterprise ID list of recruitment cases registered in the recruitment case database 124 (step S214). Next, the shared server 100 extracts members that can be disclosed to the searcher (step S215).

[0481] More specifically, the shared server 100 determines which companies should not disclose recruitment cases held by the searcher (recruiter) based on the non-public company list and public level of the recruitment case database 124. The shared server 100 classifies members belonging to such companies as members that cannot be disclosed to the searcher. The shared server 100 extracts members other than those belonging to such companies as members that can be disclosed to the searcher.

[0482] Next, the shared server 100 refers to the member database 122A to exclude the resume information of members whose resume information has been set to non-public from the extracted member information (step S216).

[0483] Next, the sharing server 100 sends the extracted member information to the retrieval request source (step S217), ending the processing based on this flowchart. The recruiter device 200, acting as the retrieval request source, receives the member information sent from the sharing server 100 and displays it on the display 205. The information displayed on the display 205 shows the extracted member's ID, name, and resume information. For members whose resume information is set to private, only the member's ID and name are displayed; the resume information is not shown.

[0484] As explained above, according to Variation 2, the recruiter can, while referring to the detailed resume information of members, search for members deemed most suitable for the recruitment business and make a reverse offer to those members. Furthermore, members displayed as search results are excluded from those that are competitors of the recruiter's company or community. Therefore, it is possible to prevent the recruiter from disclosing unfavorable business information to members of such competing companies. Moreover, since members can decide for themselves whether to disclose their resume information, a system that respects the free will of each member is provided.

[0485] Alternatively, members could not only choose whether to make their resume information public, but also whether to make their name public. Another option is to include several categories in the resume information, allowing members to choose whether to make their resume information public based on the category.

[0486] By adding the offer function described above to the matching system 1, recruiters can confirm the resume information of members who have permission to view recruitment cases. Furthermore, recruiters can urge members they wish to recruit to apply. Additionally, recruited members can urge applicants to view case information and agree or decline their applications. Moreover, members can decide whether to make their resume information public when registering or editing their information. Thus, recruiters can proactively select offer targets and bring the most suitable applicants into the business earlier.

[0487] <Variation Example 3>

[0488] Next, refer to Figures 37-41 Explain Variation Example 3. In Variation Example 3, we illustrate the member group application function that allows multiple members to apply for recruitment services in a group format.

[0489] [Background for proposing the member group recruitment function]

[0490] In crowdsourcing, generally, recruiters publicly advertise job postings, and individuals interested in the content of these jobs apply. However, there are also many comprehensive jobs, from project planning to acquiring related intellectual property rights, that require or are expected to be handled by a team of multiple people. Therefore, when the number of recruits is limited to one person, it becomes difficult for the person seeking the job to handle a workload exceeding their individual capabilities.

[0491] In Variation 3, based on this background, a member group application function is provided, allowing multiple members to apply for recruitment services in a group. Variation 3 is explained in detail below.

[0492] Figure 37 This is a block diagram illustrating the structure of the shared server 100, recruiter device 200, and applicant device 300 involved in Modification Example 3. Figure 37 In the block diagram shown, with Figure 2 Compared to the diagram shown, a member group database of 128 has been added. Figure 37 The recruitment case database 124A shown contains information on... Figure 6 The recruitment case database 124 shown has been updated with the ability to register recruitment cases that are allowed to be applied for by member groups.

[0493] Member groups consisting of multiple members are registered in member group database 128. Recruiters can use recruiter device 200 to register recruitment cases that allow applications to be submitted by member groups into recruitment case database 124A. Applicants can use applicant device 300 to apply for recruitment cases that allow applications to be submitted by member groups based on the member groups registered in member group database 128.

[0494] Figure 38 This is a diagram illustrating an example of the member group database 128 involved in Modification 3. Member group database 128 registers information about member groups. This information includes a group ID used to identify the member group, the company ID of the company to which each member belongs, and the member ID of each member.

[0495] Below, sometimes the group ID is used to refer to the member groups corresponding to each group ID as member group G1, member group G2, member group G3, etc.

[0496] Member group G1 consists of three members identified by member IDs P1, P2, and P5. The corresponding registered enterprise ID for member group G1 is 00A, therefore it can be known that all three members belong to enterprise A.

[0497] Member group G2 consists of two members identified by member IDs P1 and P3. The corresponding company IDs for member group G2 are 00A and 00B, indicating that one member belongs to company A and the other to company B. As understood by comparing member group G1 and member group G2, member ID P1 is registered in both member groups G1 and G2. Therefore, member P1 belongs to both member groups.

[0498] Member group G3 consists of four members identified by member IDs P4, P7, P8, and P14. The corresponding registered enterprise ID for member group G3 is 00C, therefore it can be known that all four members belong to enterprise C.

[0499] like Figure 37 As shown, the member group database 128 is stored in the storage device 103 of the shared server 100. Members form member groups with the consent of other members they meet through the same enterprise or community, and register the member groups in the member group database 128. A "member group" is an example of a "recruitment group".

[0500] Figure 39 This is a diagram illustrating an example of the recruitment case database 124A involved in Variation 3. Figure 39 The recruitment case database 124A shown is related to... Figure 6The recruitment case database 124A shown here has been updated with recruitment method information. The recruiter operates the recruiter device 200 to set the recruitment method. The shared server 100 registers the recruitment method and corresponding business information based on the settings into the recruitment case database 124A.

[0501] Recruiters can choose between groups and individuals as their recruitment method. If a recruiter does not select a recruitment method, the recruitment case is not limited to either groups or individuals. Cases with a group recruitment method can only be undertaken by the member group. Cases with an individual recruitment method can only be undertaken by individual members. Cases without a specified recruitment method can be undertaken by either member groups or individuals. "Recruitment method information" is an example of "information that can determine whether a recruitment undertaking is a business that should be jointly undertaken by multiple recruiters."

[0502] Figure 40 This diagram illustrates the functions of the shared server 100, recruiter device 200, and applicant device 300 in relation to Modification 3. Figure 40 In, with Figure 11 In comparison, a decision unit 145A was added to the shared server 100. Additionally, Figure 40 In, with Figure 11 In contrast, step S7A is added after step S7, replacing step S8 with step S8A of group application.

[0503] Here, it is assumed that the applicant belongs to multiple member groups. The applicant operates the applicant device 300 to retrieve recruitment cases (step S6). The applicant device 300 sends a retrieval request to the case retrieval unit 145 of the shared server 100.

[0504] Case Extraction Department 145, upon receiving a search request, if using Figure 11 As explained, recruitment cases that applicants can browse are extracted from the recruitment cases registered in the recruitment case database 124. The cases extracted by the case extraction unit 145 include those where the recruitment method is set to any of the following: "Group," "Individual," or "Unrestricted." The case extraction unit 145 sends 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).

[0505] On display 305, the disclosure level, case title, planned working hours, planned period, case content, and recruitment method are displayed for each recruitment case. When applying as a member group, the applicant uses the operation unit 306 (such as a mouse and keyboard) to specify the member group and select a case where the recruitment method is set to "Group" or "Unrestricted". The applicant device 300 processes the member group and the case to be applied for based on the applicant's operation (step S7A). The applicant device 300 sends the group ID of the processed member group and the case ID of the processed case to the shared server 100. The determination unit 145A of the shared server 100 obtains the group ID and the case ID.

[0506] The determination unit 145A accesses the member group database 128 to determine the registered member ID corresponding to the obtained group ID. The determination unit 145A then accesses the member database 122 to determine the enterprise ID corresponding to the determined member ID.

[0507] The Judgment Department 145A accesses the community database 123 to determine the community ID of the community to which the determined enterprise ID belongs. The Judgment Department 145A accesses the recruitment case database 124A to determine the registered enterprise ID (recruiter's enterprise ID), non-public enterprise ID, public level, and recruitment method corresponding to the obtained case ID.

[0508] Based on the information determined as described above, the determination unit 145A determines whether the recruitment case accepted by the applicant device 300 is a case that allows recruitment by a member group designated by the applicant. In other words, the determination unit 145A determines whether recruitment by a member group is permitted.

[0509] For example, if the decision department 145A finds that a member within the member group belongs to a company listed in the non-public company ID list corresponding to the recruitment case, the application submitted by the member group will not be permitted. Alternatively, if the recruitment case is listed as "within the community" in terms of its public level, but a member within the member group belongs to a company outside the community, the decision department 145A will not permit the application submitted by the member group.

[0510] The determination unit 145A returns the determination result to the applicant device 300. Figure 40 The diagram illustrates the process when the determination unit 145A approves an application submitted by a member group. When the determination unit 145A approves an application submitted by a member group, the applicant device 300 accepts the application submitted by the member group (step S8A). For example, the applicant device 300 displays a screen indicating that the application accepted in step S7A is approved and a screen confirming whether to submit an application on the display 305. The applicant uses the operation unit 306, such as a mouse and keyboard, to select an application.

[0511] 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 retrieves the application information. Subsequent processing and usage... Figure 11 The content is the same. However, the application department 146 sends the application information to the supervisors of each member belonging to the member group. Therefore, the application approval process in step S9 is performed by each supervisor of each member belonging to the member group. Consequently, the approval department 147 receives approval information indicating approval of a subordinate's application, or rejection information indicating whether to reject a subordinate's application, from multiple supervisors.

[0512] The approval department 147 only accepts an applicant's application after receiving approval information from the superiors of all members within the member group to which the applicant belongs. Upon accepting the applicant's application, the approval department 147 sends the application information to the recruiter device 200. (If using...) Figure 11 As already explained, the recruiter device 200 displays the application information on the display 205 (step S10). The recruiter inputs the result of their decision to accept or reject the application into the recruiter device 200. The recruiter device 200 accepts the input result (step S11) and sends the accepted result of acceptance or rejection to the notification unit 148 of the shared server 100.

[0513] The notification unit 148 sends the application results (whether the applicant is hired or not) to the applicant's device 300 and the applicant's device 300 of the supervisor (manager). Specifically, the notification unit 148 sends the application results to the supervisors of each member in the member group to which it belongs.

[0514] The applicant's applicant device 300 and the applicant devices 300 of the supervisors of each member in the member group display the application results on the display 305 (steps S12 and S13). The applicant and the supervisors of each member in the member group confirm the application results by viewing the display on the display 305.

[0515] Figure 41 This is a diagram illustrating the process of registering recruitment cases into the recruitment case database 124A, relevant to Variation 3. Figure 41 In, with Figure 13 In comparison, the recruitment method has been added to the business information input into the recruiter device 200.

[0516] In Variation 3, when a recruiter registers a recruitment case and inputs the business information and public information of the recruitment case into the recruiter device 200, the recruiter can include the recruitment method in the business information. The recruitment method can be either a group or an individual. The case registration unit 144 of the shared server 100 registers the recruitment case in the recruitment case database 124A, including the recruitment method selected by the recruiter (step S1442). If the recruiter does not select a recruitment method, the case registration unit 144 registers information indicating that the recruitment method is not limited in the recruitment case database 124A. Figure 41 Other content shown is consistent with what has already been explained. Figure 13 The same applies, so its explanation will not be repeated here.

[0517] As explained above, according to Variation 3, multiple members can apply for recruitment cases as a group. Furthermore, according to Variation 3, the approval of the member group's application is determined 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, it is possible to prevent a member group that includes members belonging to organizations that compete with the recruiter from accepting the recruiter's recruitment case.

[0518] By adding a member group recruitment function as described above to Matching System 1, a system can be provided that allows the receiving side to browse recruitment cases and recruit cases through member group recruitment. Thus, Matching System 1 can handle the posting and acceptance of large-scale business that is desired to be conducted in a team format.

[0519] <Variation Example 4>

[0520] Figure 42 This is a diagram showing the structure of the matching system 1A related to variant example 4. (See diagram for example.) Figure 42 As shown, the functions of the shared server 100 can also be distributed across the systems within each enterprise. That is, as the matching system 1, a distributed management matching system 1A can be used instead of a centralized management matching system 1.

[0521] Figure 42 The system architecture shown is common to enterprises A, B, C, D, etc. Each enterprise is equipped with a user device 500, a database 520, and a storage device 503 for storing the database. When a member operates the user device 500 as a recruiter, the user device 500 functions as a recruiter device 200. When a member operates the user device 500 as an applicant, the user device 500 functions as an applicant device 300.

[0522] User device 500 is, for example, composed of a server. User device 500 is an example of a computing device that includes recruiter device 200 and applicant device 300. User device 500, like recruiter device 200 and applicant device 300, has a processor, memory for storing programs required for processor operation, and communication interface, etc.

[0523] Database 520 has Figure 2 The functions of database 120 shown include recruitment case database 524, which replaces recruitment case database 124, and various other databases. Recruitment case database 524 for company A records recruitment cases initiated by employees of company A as recruiters. Recruitment case database 524 for company B records recruitment cases initiated by employees of company B as recruiters. Similarly, recruitment cases initiated by employees of each company as recruiters are recorded in the recruitment case databases 524 for other companies.

[0524] Public license list 521 is registered in database 520. Public license list 521 contains a list of groups (businesses, communities, etc.) that have licensed public solicitation cases. Public license list 521 contains... Figure 6 The information registered in the recruitment case database 124 shown corresponds to the "List of Non-Public Enterprise IDs" and the "Publicity Level". The user device 500 registers the recruitment cases (business information) and the public license list 521 (public information) indicating the scope of public disclosure of the recruitment cases in the database 520.

[0525] User device 500 of Company A determines, based on the public license list 521, which companies or communities should publicly disclose recruitment offers and which should not. Based on this decision, user device 500 of Company A sends recruitment offers to the respective companies or communities. For example, if user device 500 of Company A decides to disclose a recruitment offer to Company C but not to Companies B and D, it sends the recruitment offer to Company C but not to Companies B and D.

[0526] The user devices 500 of companies B, C, D, etc., also operate based on the public license list 521, just like the user device 500 of company A. In this way, the user device 500 determines, based on the public license list 521, which recruitment cases registered in the database 520 are allowed to be disclosed to applicants, and provides the recruitment cases that are allowed to be disclosed to applicants to the applicant device 300.

[0527] According to Variation 4, it is not necessary to set up a server within the matching system for centrally managing the system.

[0528] <Variation Example 5>

[0529] use Figure 43 Explain variation example 5. Figure 43 This is a diagram illustrating an example (Variation 5) of applying Kerberos authentication to matching system 1A. It can also be seen as... Figure 43 As shown, Kerberos authentication is applied to inter-enterprise authentication in matching system 1A. Kerberos authentication is one of the network authentication methods used between servers and clients.

[0530] Here, we will use companies A and C from among multiple companies as examples to illustrate variation 5. For example... Figure 43 As shown, authentication system 510A is configured in enterprise A, and authentication system 510C is configured in enterprise C. Authentication system 110 is a KDC (Key Distribution Center). Authentication system 110 is operated, for example, by a certification authority. Authentication system 110 consists of servers configured within the certification authority. Authentication systems 510A and 510C are, for example, user devices 500 (see reference). Figure 42 )constitute.

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

[0532] Here, we illustrate an example where company A sends a recruitment application to company C after company A has performed Kerberos authentication. Therefore, company A is the recruiter, and company C is the applicant. First, authentication system 510A requests authentication from authentication system 110 (step Sk101). For example, authentication system 510A sends the authentication information required for login, such as the ID and password, to authentication system 110's AS. Authentication system 510A may also use a public authentication key method in the authentication procedure.

[0533] After the AS of authentication system 110 authenticates the information received from authentication system 510A, it sends the TGT to authentication system 510A (step Sk102). Authentication system 510A performs license authentication of the case and obtains the license to issue the service ticket (step Sk103).

[0534] Next, authentication system 510A requests a service ticket for enterprise C from the TGS of authentication system 110 (step Sk104). At this time, authentication system 510A presents the TGT issued by AS to TGS. After verifying the TGT, TGS sends the service ticket for enterprise C to authentication system 510A (step Sk105).

[0535] Next, in order to obtain a transmission permission from Enterprise C, authentication system 510A sends a service ticket to Enterprise C's authentication system 510C (step Sk106). Authentication system 510C obtains the service ticket. Authentication system 510C then sends the data transmission permission to authentication system 510A (step Sk107).

[0536] Subsequently, authentication system 510A sends to authentication system 510C the recruitment cases registered in recruitment case database 524 that are permitted to be disclosed to company C by the public license list 521. Thus, company A can enable applicants from company C to view its recruitment cases. Alternatively, instead of storing each company's public license list 521 separately, authentication system 110 can store the public license lists 521 of all companies. In this case, authentication system 110 has the function of determining the viewing permissions for recruitment cases.

[0537] When Kerberos authentication is applied in Matching System 1, Company A can simplify the authentication process when sending cases to companies other than Company C by utilizing the acquired TGT. For example, if Company A wants to send a case to Company D, its authentication system 510A, after presenting the acquired TGT, requests a service ticket for Company D from the TGS. If the TGT is valid, the TGS issues a service ticket for Company D to its authentication system 510A.

[0538] By utilizing Kerberos authentication as described above, a single sign-on method can be installed in matching system 1. As a result, for example, when sending recruitment data from company A to other companies, authentication per company is unnecessary. Furthermore, companies A and C are shown here as an example of multiple companies. However, Kerberos authentication as described above can also be applied as an authentication method between three or more companies.

[0539] According to the implementation method described above, the publishing company can provide case information only to a limited number of companies, thus preventing the leakage of confidential information. The receiving company can receive case information from companies whose reliability is guaranteed by the matching system 1, 1A, thus obtaining highly reliable case information.

[0540] According to this implementation method, recruiters can set companies as non-public targets separately from the public level (see [reference]). Figure 13 That is, in this embodiment, the recruiter device 200 accepts the operation of inputting a target group (enterprises that are not publicly disclosed) for which business information is prohibited from being disclosed, and sends information that can identify the target group ("non-public targets" in "public information") to the shared server 100. Even if the disclosure level is the level that allows disclosure of business information to the target group (disclosure level), the shared server 100 prohibits the disclosure of business information to applicants belonging to the target group (S1442). Therefore, according to this embodiment, it is possible to individually set the enterprises for which public recruitment cases are to be restricted.

[0541] According to this embodiment, the manager of the employee's company can confirm the content of the work undertaken by the employee, thus preventing the leakage of confidential information. Furthermore, according to this embodiment, the company on the receiving end can track the employee's primary and secondary work hours. Therefore, the company on the receiving end can manage the employee's health.

[0542] As explained above, this embodiment provides a matching system 1, 1A that functions as a crowdsourcing platform. To find more suitable talent through crowdsourcing, it is desirable to further expand the scope of crowdsourcing, rather than limiting it to a specific company or a small number of companies. In this case, it is necessary to consider the interests of the recruiter who undertakes the recruitment task and the applicant who applies for the recruitment. According to the matching system 1, 1A of this embodiment, suitable applicants who take into account the interests between the recruiter and the applicant can be selected.

[0543] The shared server 100 and user device 500 are examples of computing devices capable of communicating with applicant devices and accessing databases. The shared server 100 and user device 500 register business information and public information indicating the scope of disclosure of the business information in databases 120 and 520. Based on the public information, the shared server 100 and user device 500 determine which business information registered in databases 120 and 520 is permitted to be disclosed to applicants, and provide (send) the permitted business information to applicant device 300. The shared server 100 and user device 500 determine whether disclosure is permitted for the first applicant, the second applicant, and the third applicant respectively, according to the disclosure level (step S1452A).

[0544] The public information is categorized into multiple disclosure levels, including "Same Company," "Community," and "Unrestricted." These disclosure levels include a first level and a second level. The first level (e.g., "Within Our Company") corresponds to the following (see reference). Figure 22): Disclosing business information to the first applicant belonging to the first group is permitted, but disclosing business information to applicants not belonging to the first group is prohibited. The second level (e.g., "within the community") corresponds to the following situations (see...). Figure 22 Level 3 allows applicants to disclose business information to any group within the first group and any community group that has a community relationship with the first group; it prohibits disclosing business information to applicants who do not belong to the first group or any of the community groups. Level 3 corresponds to the following situations (see...). Figure 22 (Variation of the above): Business information may be disclosed to applicants who belong to the first group and to specific community groups that have formed a community relationship with the first group but are different from the second level; business information may not be disclosed to applicants who do not belong to either the first group or any of the specific community groups.

[0545] Multiple disclosure levels include disclosure levels corresponding to situations where business information is allowed to be disclosed to applicants regardless of their group affiliation (see [reference]). Figure 22 The databases 120 and 520 contain attribute data (community ID) that can identify community groups. The shared server 100 and user device 500 use the publicly available information and attribute data to determine applicants who are allowed to disclose business information.

[0546] When the shared server 100 and user device 500 receive input from a target group that prohibits the disclosure of business information (the enterprise ID of the enterprise that is not a public target), even if the disclosure level is a level that allows the disclosure of business information to the target group, they prohibit the disclosure of business information to applicants belonging to the target group.

[0547] The shared server 100 receives a request from the recruiter device 200 to retrieve information on multiple registrants (members) registered in the database 120 (step S21), and provides the retrieval results based on the received request to the recruiter device (step S22). The recruiter device 200 accepts the recruiter's operation of selecting a recommended applicant from the retrieval results (step S23), and sends the identification information of the selected applicant recommender (set as the member ID of the member to whom the reverse offer is made) to the shared server 100. The shared server 100 sends a message urging the applicant to apply to the recruiter device 300 of the selected applicant recommender (step S24).

[0548] Shared server 100 registers multiple resumes of each registrant (member) into the database 120 (see reference). Figure 35The shared server 100 accepts input from each of the multiple registrants for setting the scope of public disclosure of multiple resume information as search results (handling settings for whether to allow disclosure based on the type of resume information). The shared server 100 also accepts recruitment method information. Figure 41 The input of the recruitment method (shown) is information that can determine whether the business to be recruited is a group business that can be undertaken when multiple applicants apply together, or a business that can be undertaken when a single applicant applies. The shared server 100 registers the recruitment method information and the business information in the database 120 (step S1442).

[0549] The shared server 100 registers application groups (member groups) consisting of multiple applicants into the database 120. The shared server 100, regarding business information that can be disclosed to all applicants belonging to an application group, is subject to the application process conducted by the application group (determination unit 145A).

[0550] This embodiment has the following structures.

[0551] (a-1) An evaluation system for evaluating contractors who have applied for services, the evaluation system comprising: a first evaluator device operated by one or more evaluators belonging to a first group; and a computing device that communicates with the first evaluator device and is capable of accessing a database, wherein the first evaluator device accepts input for evaluations of contractors and sends the accepted evaluations to the computing device, the computing device registers first evaluation information based on the evaluations received from the first evaluator device in the database according to the contractors, and the computing device, upon receiving a browsing request in a first communication established through identification information that identifies a person belonging to the first group, sends the first evaluation information to the sending source that sent the browsing request in the first communication.

[0552] (a-2) It also includes a second evaluator device operated by one or more evaluators belonging to a second group different from the first group. The second evaluator device accepts input for the evaluation of the recipient and sends the accepted evaluation to the computing device. The computing device registers the second evaluation information based on the evaluation received from the second evaluator device in the database according to the recipient. When the computing device receives a browsing request in a second communication established through identification information that can identify the person who belongs to the second group, it sends the second evaluation information to the sending source that sent the browsing request in the second communication.

[0553] (a-3) The first group consists of the first enterprise, and the second group consists of the second enterprise which is different from the first enterprise.

[0554] (a-4) The first group consists of the first department of the first enterprise, and the second group consists of the second department of the first enterprise.

[0555] (a-5) When the computing device receives evaluations of the specified receiver from multiple evaluators belonging to the first group, it calculates the average value of the evaluations of the specified receiver from the multiple evaluators, and sends the average value as the first evaluation information of the specified receiver to the sending source that sent the browsing request in the first communication.

[0556] (a-6) The first group includes one or more evaluators belonging to the first segmented group and one or more evaluators belonging to a second segmented group different from the first segmented group. The computing device calculates the average value of the evaluations of the specified receiver, i.e., the first average value, based on the evaluations of the specified receiver received from multiple evaluators belonging to the first segmented group. The computing device calculates the average value of the evaluations of the specified receiver, i.e., the second average value, based on the evaluations of the specified receiver received from multiple evaluators belonging to the second segmented group. The computing device calculates the average value of the evaluations of the specified receiver, i.e., the third average value, based on the evaluations of the specified receiver received from multiple evaluators belonging to the first group. When the computing device receives a browsing request in a third communication established through identification information that can identify a person belonging to the first segmented group, it sends the first average value and the third average value as the first evaluation information of the specified receiver to the sending source that sent the browsing request in the third communication. When the computing device receives a browsing request in a fourth communication established through identification information that can identify a person belonging to the second segmented group, it sends the second average value and the third average value as the first evaluation information of the specified receiver to the sending source that sent the browsing request in the fourth communication.

[0557] (a-7) A list of recipients is registered in the database. When the first evaluator device accepts the operation of searching the list, it sends a search request to the computing device. When the computing device receives the search request, it sends the search results, after excluding recipients whose evaluation level determined by the first evaluation information does not meet the benchmark, to the sending source that sent the browsing request in the first communication.

[0558] (a-8) In the database, multiple business information is registered together with public information indicating the scope of disclosure to applicants. The evaluation system also has an applicant device operated by applicants belonging to the second group. The computing device determines, based on the public information, the business information among the multiple business information registered in the database that is allowed to be disclosed to applicants belonging to the second group, and provides the business information that is allowed to be disclosed to applicants belonging to the second group to the applicant device.

[0559] (a-9) An evaluator device operated by one or more evaluators belonging to a first group, the evaluator device comprising: an interface for accepting input of an evaluation corresponding to a service recipient; a receiving unit for accepting browsing requests; a display; and a processor for sending the evaluation received by the interface and the browsing request received by the receiving unit to a computing device capable of accessing a database, wherein, in the event of a browsing request, the processor displays the evaluation performed by one or more evaluators belonging to the first group on the display.

[0560] (a-10) A method for evaluating a contractor who has applied for a business, the method comprising the steps of: communicating with a first evaluator device operated by one or more evaluators belonging to a first group; receiving an evaluation of the contractor from the first evaluator device; registering first evaluation information based on the evaluation received from the first evaluator device in a database; and, when a browsing request is received in a first communication established by means of identification information that identifies a person belonging to the first group, sending the first evaluation information to the sending source that sent the browsing request in the first communication.

[0561] (b-1) An evaluation system for evaluating recruiters of recruitment services, the evaluation system comprising: a first evaluator device operated by one or more evaluators belonging to a first group; and a computing device communicating with the first evaluator device and capable of accessing a database, wherein the first evaluator device accepts input for evaluations of recruiters and sends the accepted evaluations to the computing device, the computing device registers first evaluation information based on the evaluations received from the first evaluator device in the database according to the recruiters, and the computing device, upon receiving a browsing request in a first communication established through identification information that identifies a person belonging to the first group, sends the first evaluation information to the sending source that sent the browsing request in the first communication.

[0562] (b-2) It also includes a second evaluator device operated by one or more evaluators belonging to a second group different from the first group. The second evaluator device accepts input for the evaluation of the recruiter and sends the accepted evaluation to the computing device. The computing device registers the second evaluation information based on the evaluation received from the second evaluator device in the database according to the recruiter. When the computing device receives a browsing request in a second communication established through identification information that can identify the person who belongs to the second group, it sends the second evaluation information to the sending source that sent the browsing request in the second communication.

[0563] (b-3) The first group consists of the first enterprise and the second group consists of the second enterprise which is different from the first enterprise.

[0564] (b-4) The first group consists of the first division of the first enterprise, and the second group consists of the second division of the first enterprise.

[0565] (b-5) When the computing device receives evaluations of the specified recruiter from multiple evaluators belonging to the first group, it calculates the average of the evaluations of the specified recruiter from the multiple evaluators, and sends the average as the first evaluation information of the specified recruiter to the sending source that sent the browsing request in the first communication.

[0566] (b-6) The first group includes one or more evaluators belonging to the first segmented group and one or more evaluators belonging to a second segmented group different from the first segmented group. The computing device calculates the average of the evaluations of the specified recruiter, i.e., the first average, based on the evaluations of the specified recruiter received from multiple evaluators belonging to the first segmented group. The computing device calculates the average of the evaluations of the specified recruiter, i.e., the second average, based on the evaluations of the specified recruiter received from multiple evaluators belonging to the second segmented group. The computing device calculates the average of the evaluations of the specified recruiter, i.e., the third average, based on the evaluations of the specified recruiter received from multiple evaluators belonging to the first group. When the computing device receives a browsing request in a third communication established through identification information that can identify a person belonging to the first segmented group, it sends the first average and the third average as the first evaluation information of the specified recruiter to the sending source that sent the browsing request in the third communication. When the computing device receives a browsing request in a fourth communication established through identification information that can identify a person belonging to the second segmented group, it sends the second average and the third average as the first evaluation information of the specified recruiter to the sending source that sent the browsing request in the fourth communication.

[0567] (b-7) A list of recruiters is registered in the database. When the first evaluator device accepts the operation of searching the list, it sends a search request to the computing device. When the computing device receives the search request, it sends the search results, after excluding recruiters whose evaluation level determined by the first evaluation information does not meet the benchmark, to the sending source that sent the browsing request in the first communication.

[0568] (b-8) In the database, multiple business information is registered together with public information indicating the scope of disclosure to applicants. The evaluation system also has an applicant device operated by applicants belonging to the second group. The computing device determines, based on the public information, the business information among the multiple business information registered in the database that is allowed to be disclosed to applicants belonging to the second group, and provides the business information that is allowed to be disclosed to applicants belonging to the second group to the applicant device.

[0569] (b-9) An evaluator device operated by one or more evaluators belonging to a first group, the evaluator device comprising: an interface for accepting input of an evaluation of a recruiter for a recruitment application business; a receiving unit for accepting browsing requests; a display; and a processor for sending the evaluation received by the interface and the browsing request received by the receiving unit to a computing device capable of accessing a database, wherein, in the event of a browsing request, the processor displays the evaluation performed by one or more evaluators belonging to the first group on the display.

[0570] (b-10) A method for evaluating recruiters in a recruitment business, the method comprising the steps of: communicating with a first evaluator device operated by one or more evaluators belonging to a first group; receiving evaluations of recruiters from the first evaluator device; registering first evaluation information based on the evaluations received from the first evaluator device in a database; and, when a browsing request is received in a first communication established by identification information that identifies a person belonging to the first group, sending the first evaluation information to the sending source that sent the browsing request in the first communication.

[0571] (c-1) A matching system for matching recruiters of recruitment services with applicants, the matching system comprising: a first applicant device operated by a first applicant; and a computing device capable of communicating with the first applicant device and accessing a database, wherein the computing device registers recruitment service information and public information indicating the scope of disclosure of the service information in the database, the computing device determines, based on the public information, the service information registered in the database that is permitted to be disclosed to the first applicant, the service information including detailed information related to the content of the service, and the computing device displays the service information permitted to be disclosed to the first applicant and the terms included in the detailed information on the first applicant device.

[0572] (c-2) The language included in the details is internal language that is common in the group to which the recruiter belongs.

[0573] (c-3) The computing device registers internal terms and their meanings in a database.

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

[0575] (c-5) If the first applicant’s operation on the internal terminology is detected in the first applicant’s device, the computing device sends information registered in the database that can determine the meaning of the internal terminology to the first applicant’s device.

[0576] (c-6) The computing device retrieves internal terms contained in the detailed information and registers the business information in the database by matching the detected internal terms with their meanings.

[0577] (c-7) A computing device comprising a matching system for matching recruiters and applicants for recruiting business operators, the computing device having: a communication interface for communicating with a first applicant device operated by a first applicant; and a processor for accessing a database, wherein the processor registers business information for recruiting business operators and public information indicating the scope of disclosure of the business information in the database, the processor determines, based on the public information, business information registered in the database that is permitted to be disclosed to the first applicant, the business information containing detailed information relating to the content of the business, and the processor displays the business information permitted to be disclosed to the first applicant and the meaning of terms contained in the detailed information on the first applicant device.

[0578] (c-8) A method for matching recruiters and applicants for a recruitment business, the method comprising the steps of: communicating with a first applicant device operated by a first applicant; registering recruitment business information and public information indicating the scope of disclosure of the business information in a database; and determining, based on the public information, business information in the business information registered in the database that is permitted to be disclosed to the first applicant, wherein the business information contains detailed information related to the content of the business, the method further comprising the step of: displaying the business information permitted to be disclosed to the first applicant and the meaning of terms contained in the detailed information on the first applicant device.

[0579] (d-1) The user device includes a second applicant device operated by a second applicant who is different from the first applicant. The computing device determines, based on publicly available information, which 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 device.

[0580] (d-2) The user device includes a third applicant device operated by a third applicant who is different from the first applicant and the second applicant. The third applicant has multiple disclosure levels for the public information. The computing device determines whether to allow disclosure for the first applicant, the second applicant and the third applicant respectively according to the disclosure level.

[0581] (d-3) The first applicant belongs to the first group, and the second applicant belongs to the second group, which is different from the first group. There are multiple disclosure levels, including the first level and the second level. The first level corresponds to the following: it is allowed to disclose the business case to the first applicant, and it is prohibited to disclose the business case to applicants who do not belong to the first group. The second level corresponds to the following: it is allowed to disclose the business case to applicants who belong to the first group and to any group in the community group that has formed a community relationship with the first group, and it is prohibited to disclose the business case to applicants who do not belong to the first group and any group in the community group.

[0582] (d-4) The first applicant belongs to the first group, and the second applicant belongs to the second group, which is different from the first group. There are multiple disclosure levels, including the first level, the second level, and the third level. The first level corresponds to the following: business cases are allowed to be disclosed to the first applicant, and business cases are prohibited from being disclosed to applicants who do not belong to the first group. The second level allows disclosure of business cases to applicants who belong to the first group and to any group in the community groups that have formed a community relationship with the first group. The third level corresponds to the following: business cases are allowed to be disclosed to applicants who belong to the first group and to a specific community group that has formed a community relationship with the first group and is different from the second level community group, and business cases are prohibited from being disclosed to applicants who do not belong to either the first group or any of the specific community groups.

[0583] (d-5) Multiple disclosure levels include disclosure levels corresponding to situations where business cases are allowed to be disclosed to applicants regardless of the group to which the applicant belongs.

[0584] (d-6) The database contains attribute data that can identify community groups. The computing device uses the publicly available information and attribute data to identify applicants who are allowed to disclose business cases.

[0585] (d-7) When the computing device receives input from a target group to which disclosure of business cases is prohibited, it prohibits disclosure of business cases to applicants belonging to that target group, even if the disclosure level is one that allows disclosure of business cases to the target group.

[0586] (d-8) The computing device receives a request from the recruiter device to retrieve information on multiple registrants registered in the database, and provides the retrieval results based on the received request to the recruiter device. The recruiter device accepts the recruiter's operation of selecting a recommended applicant from the retrieval results to apply for the position, and sends the identification information of the selected applicant to the computing device. The computing device sends a message urging the applicant to apply to the applicant device of the selected applicant.

[0587] (d-9) The computing device registers multiple resume information of multiple registrants in the database, and the computing device accepts input from multiple registrants to set the scope of the multiple resume information to be published as search results.

[0588] (d-10) When the computing device receives input that determines whether a business to be recruited is a group business that can be taken on when multiple applicants apply together, or a business that can be taken on when a single applicant applies, the recruitment method information is registered in the database in correspondence with the business case.

[0589] (d-11) The computing device registers a group of applicants consisting of multiple applicants in a database, and the computing device is able to make an application for a business case that is permitted to be disclosed to all applicants belonging to the group of applicants based on the application of the group of applicants.

[0590] [Way]

[0591] The following are examples of the methods of this disclosure.

[0592] (First item) The matching system described in the first item is used to match business cases. The matching system includes: a user device operated by a user; and a computing device configured to access a database containing registered business cases and disclose business cases to the user. 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 computing device sets the disclosure scope of business cases provided by the second user based on disclosure information indicating the disclosure scope of business cases. The first user device sends restriction information to the computing device based on the operation of the first user, restricting the disclosure of business cases to the first group. Regardless of the disclosure scope set based on the disclosure information, the computing device restricts the disclosure of business cases provided by the second user to the first group according to the restriction information.

[0593] (Second item) Regarding the matching system described in the second item, according to the matching system described in the first item, the restriction information includes any one of the following: user specification information for specifying the user as the subject of restriction, industry type specification information for specifying the industry type as the subject of restriction, and enterprise specification information for specifying the enterprise as the subject of restriction.

[0594] (Third item) Regarding the matching system described in the third item, according to the matching system described in the second item, the second user belongs to the second group, and the user-specified information includes information for specifying the second group.

[0595] (Fourth item) Regarding the matching system described in the fourth item, according to the matching system described in any one of the first to third items, 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 send restriction information on the first case and restriction information on the second case to the computing device based on the operation of the first user.

[0596] (Fifth item) Regarding the matching system described in the fifth item, according to the matching system described in any one of the first to fourth items, if the first user is a person with the authority to set restriction information, the first user device sends restriction information to the computing device.

[0597] (Sixth item) Regarding the matching system described in the sixth item, according to the matching system described in any one of the first to fifth items, the second user device sends public information to the computing device based on the operation of the second user.

[0598] (Seventh item) Regarding the matching system described in the seventh item, according to the matching system described in any one of the first to sixth items, the user device includes a first applicant device operated by the first applicant, and the computing device determines, based on public information and restricted information, the business cases registered in the database that are permitted to be disclosed to the first applicant, and provides the business cases permitted to be disclosed to the first applicant device.

[0599] (Eighth item) Regarding the matching system described in the eighth item, according to the matching system described in any one of the first to seventh items, the user device includes a recruiter device operated by the recruiter, which sends business cases and public information to the computing device.

[0600] (Ninth item) Regarding the matching system described in the ninth item, according to the matching system described in any one of the first to seventh items, the user device includes a recruiter device operated by the recruiter, and the computing device includes the recruiter device.

[0601] (Item 10) The user device described in Item 10 communicates with a computing device that matches business cases, wherein the computing device is configured to access a database containing registered business cases and disclose the business cases to a user, and the computing device sets the scope of disclosure of the business cases based on disclosure information and restriction information indicating the scope of disclosure of the business cases, and the user device includes: a receiving unit that accepts user operations that input restriction information; and a sending unit that, when the receiving unit accepts the user operation, sends restriction information to the computing device, wherein the restriction information restricts the disclosure of business case information to a first group to which the first user belongs, regardless of the scope of disclosure based on the disclosure information.

[0602] (Item 11) The computing device described in Item 11 is a computing device for matching service cases that communicates with a user device, and includes: a setting unit that accesses a database in which service cases are registered and sets service cases to be disclosed to a first group to which a first user belongs based on disclosure information indicating the scope of disclosure of the service cases; a receiving unit that receives restriction information from the user device that restricts the disclosure of service cases to the first group; and a restriction unit that, upon receiving the restriction information, restricts the disclosure of service cases to the first group based on the restriction information, regardless of the scope of disclosure set based on the disclosure information.

[0603] (Item 12) The method described in Item 12 is a method for matching business cases, comprising the following steps: accessing a database in which business cases are registered; setting business cases to be disclosed to a first group to which a first user belongs based on public information indicating the scope of disclosure of the business cases; receiving restriction information from a user device restricting 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 based on the restriction information, regardless of the scope of disclosure set based on the public information.

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

[0605] Explanation of reference numerals in the attached figures

[0606] 1: Matching system; 50: Internet; 100: Shared server; 101: Processor; 102: Memory; 103, 503: Storage device; 104: Communication interface; 120, 520: Database (DB); 121: Enterprise database (Enterprise DB); 122, 122A: Member database (Member DB); 123: Community database (Community DB); 124, 124A, 524: Recruitment case database (Recruitment case DB); 125: Side hustle database (Side hustle 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: Company Terminology Database (Company Terminology DB); 140: Community Registration Department; 141: Enterprise Registration Department; 142: Member Registration Department; 143: Member Search Department; 144: Case Registration Department; 145: Case Extraction Department; 145A: Member Group Information Acquisition Department; 146: Application Department; 147: Approval Department; 148: Notification Department; 149: Performance Acceptance Department; 150: Performance Output Department; 151: Evaluation Acceptance Department; 152: Evaluation Output Department; 161: Reverse Offer Commissioning Department; 162: Reverse Offer Approval Commissioning Department; 163: Reverse Offer Commissioning Acceptance Notification Department; 200, 200A, 200B, 200C: Recruiter Device; 201: Processor; 202: Memory; 203: Communication Interface; 204: Input / Output Interface; 205: Display; 206: Operation unit; 206A: Keyboard; 206B: Mouse; 300, 300A, 300B, 300C: Applicant device; 301: Processor; 302: Memory; 303: Communication interface; 304: Input / output interface; 305: Display; 306: Operation unit; 306A: Keyboard; 306B: Mouse; 307A~307C: Tags; 308: Cursor; 401, 402: Table; 500: User device; 521: Public license list; 551, 552: Screen; 1271, 1272: Data set.

Claims

1. A matching system for matching business cases, the matching system comprising: a user device operated by a user; and a computing device configured to access a database in which the business cases are registered, and to disclose the business cases to the user, the user device including 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 computing device setting a disclosure range of a business case provided by the second user based on disclosure information indicating a disclosure range of the business case, the first user device sending restriction information for restricting disclosure of business cases to the first group to the computing device based on an operation of the first user, the computing device restricting disclosure of the business case provided by the second user to the first group in accordance with the restriction information regardless of the disclosure range set based on the disclosure information.

2. The matching system according to claim 1, wherein the restriction information includes any one of user designation information for designating a user as a restriction target, industry type designation information for designating an industry type as a restriction target, and enterprise designation information for designating an enterprise as a restriction target.

3. The matching system according to claim 2, wherein the second user belongs to a second group, and the user designation information includes information for designating the second group. wherein 4. The matching system according to any one of claims 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 send the restriction information for the first case and the restriction information for the second case to the computing device based on an operation of the first user.

5. The matching system according to any one of claims 1 to 4, wherein the first user device sends the restriction information to the computing device in a case where the first user is a person having a right to set the restriction information.

6. The matching system according to any one of claims 1 to 5, wherein the second user device sends the disclosure information to the computing device in accordance with an operation of the second user.

7. The matching system according to any one of claims 1 to 6, wherein the user device includes a first applicant device operated by a first applicant, the computing device determines a business case that is allowed to be disclosed to the first applicant among the business cases registered in the database based on the disclosure information and the restriction information, and provides the business case allowed to be disclosed to the first applicant to the first applicant device.

8. The matching system according to any one of claims 1 to 7, wherein the user device includes a recruiter device operated by a recruiter, and the recruiter device sends the business case and the disclosure information to the computing device.

9. The matching system according to any one of claims 1 to 7, wherein the user device includes a recruiter device operated by a recruiter, and the computing device includes the recruiter device. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ 10. A user device that communicates with a computing device that matches business cases, wherein the computing device is configured to access a database in which the business cases are registered and to disclose the business cases to users, the computing device sets a disclosure range of the business cases based on disclosure information and restriction information that indicate a disclosure range of the business cases, the user device has: a reception unit that receives a user operation that inputs the restriction information; and a transmission unit that transmits the restriction information to the computing device in a case where the user operation is received by the reception unit, the restriction information restricts disclosure of the business cases to a first group to which a first user belongs regardless of the disclosure range based on the disclosure information.

11. A computing device that communicates with a user device for matching business cases, the computing device has: a setting unit that accesses a database in which the business cases are registered and sets business cases that are disclosed to a first group to which a first user belongs based on disclosure information that indicates a disclosure range of the business cases; a reception unit that receives restriction information that restricts disclosure of the business cases to the first group from the user device; and a restriction unit that restricts disclosure of the business cases to the first group according to the restriction information regardless of the disclosure range set based on the disclosure information in a case where the restriction information is received.

12. A method of matching business cases, the method includes: accessing a database in which the business cases are registered and setting business cases that are disclosed to a first group to which a first user belongs based on disclosure information that indicates a disclosure range of the business cases; receiving restriction information that restricts disclosure of the business cases to the first group from a user device; and restricting disclosure of the business cases to the first group according to the restriction information regardless of the disclosure range set based on the disclosure information in a case where the restriction information is received. ​ ​

Images