METHOD AND APPARATUS FOR INTEGRATING AUTOMATED WORKFORCE MANAGEMENT SYSTEMS AND WORK INTERMEDIATION PLATFORMS

A system assumes control over selected functionality in servers configured as a computerized work management systems (WMSs) and other servers configured as computerized work intermediation platforms (WIPs) to form communication channels therebetween. The system includes an integration platform responsive to actions at the WMS and the WIPs to communicate all data originating at the WMS and destined for the WIPs, and to communicate all data originating at the WIPs and destined for the WMS. The platform provides the WMSs with a set of same protocols and the WIPs with another set of same protocols for establishing the data communication channels with the platform as an intermediary. The system also includes an agent that embeds a sourcing GUI into the GUI suite of the WMS, and a talent architecture hosted on another server remote from those of the WMSs and the WIPs that responds to the sourcing GUI.

FIELD OF THE INVENTION

The invention relates generally to computer networks, and more particularly to a system and a method for establishing channels of communication between a special purpose server maintained in a restricted environment within a company engaged in hiring or by a software vendor contracted by a company which is engaged in hiring and publically accessible servers accessible to talented professionals seeking employment but inaccessible to the special purpose server used by the hiring company. The invention also relates to directing communications in a highly efficient way once the channels have been opened.

BACKGROUND OF THE INVENTION

Competition for talent is fierce. While workforce capabilities are rated one of the top five most important organizational challenges today, 61% of companies are struggling to find skilled workers. These companies are experiencing delays in filling high-demand positions, with the average time-to-fill exceeding 25 calendar days. They also are facing rising talent costs with an overall wage increase of around 10% since 2006, and 3% year over year since 2012 in Information Technology (IT) alone.

Traditionally, enterprise companies that use a managed services provider (MSP), vendor management system (VMS) or the like have relied almost exclusively on staffing and service suppliers to fulfill at least their contingent workforce needs. Using the IT field again as an example, we find that the average markup, namely the cost of recruiting and paying, that is charged by a staffing company in the United States for a contingent worker is 42% or higher. Moreover, the suppliers themselves are fishing from the same “human capital ponds” (e.g. Linkedin® and Facebook®) as their competitors, and these ponds are being fished dry. By solely outsourcing the process of finding talent to suppliers, companies are limiting their pipeline of available qualified talent, missing opportunities to lower their total talent cost, and struggling to meet the resource demands of their business.

FIGS. 1 and 2are network diagrams that show two exemplary environments for which the present invention establishes new channels of communication. We will refer to a hiring company's MSP, VMS and the like as integrated in a Work Management System (WMS).FIG. 1shows exemplary hiring company10with a WMS12hosted on a server20. It is understood that company10could license WMS12such that the WMS would not reside at the company but instead company10would access the WMS remotely. WMS12is shown to include a master controller22(e.g. CPU), memory24, display manager26, database interface28, a restricted network communications interface30, hiring functionality32, contract work management functionality34, managing processor36, and one or more secure workstations14a,14bconnected to the server through the communications interface over the internet or a local area network (LAN)16. Interface28accesses databases18a,18b, the contents of which and processing of data from which generally are proprietary to hiring company10and so access to WMS12generally is restricted to authorized users within the company. Database18acontains proprietary data related to hiring and employment, such data including a description of and requirements for each position required by the company10, onboarding requirements for such position for filling the position, form contracts, forms for altering contracts and the like. Database18bcould comprise accounting records, customer lists, and other routine proprietary business data. Hiring functionality32contains business rules for evaluating among different job applicants, referred to as candidates, for a particular job to select and hire qualified candidates, and, frequently, further rules for distinguishing among such candidates. Hiring functionality32also contains business rules for evaluating responses from professionals for an “RFx”, which is a request for information, a request for proposal and the like, and responses from professionals for a statement of work (SOW). A RFx may be used to determine which professional should be engaged in a SOW in order to have project based work fulfilled. Contract work management functionality34contains business rules for managing the necessary fulfillment and alterations of contingent contract jobs and contract SOW engagements.

Limited access to WMS12is granted to authorized talent suppliers50a,50b, and50cover the internet through communications interface30. This is so that the hiring company10can publish job opportunities, RFxs, SOWs, hereafter collectively referred to as work opportunities, and their requirements to its traditional suppliers, and the suppliers can respond with suggested candidates, responses to RFxs, and responses to SOWs. Otherwise, public access by individuals and other machines is denied. These restrictions, however, also block access to new platforms increasingly used by skilled individuals in searching for permanent job opportunities, contingent job opportunities and SOW engagements.

FIG. 2is a network diagram of a very important new platform known as a Work Intermediation Platform (WIP). WIPs have been described as a digital infrastructure that enables business users from hiring companies to directly locate and engage available talent to perform work for a specific time and cost. InFIG. 2, exemplary WIP100is shown as networking plural hiring companies10a,10b,10cwith each other and with hundreds or thousands of individuals (professionals) who are seeking job opportunities over the internet via personal client devices120a,120b,120cetc. such as cellular phones, personal computers, tablets, personal digital assistants and the like. Each individual job seeker becomes a user, e.g. subscriber, at WIP100by opening an account on the WIP to publish his or her credentials and availability for work. WIPs represent a fundamental shift in how talented individuals now engage for work. For example, they are available to retirees hoping to become independent workers, as well as Generation Y workers or millennials with entrepreneurial ambitions. WIPs tend to cater to a workforce focused less on long term, full-time relationships and more on short term opportunities and experiences across different companies, geographies, and in some cases skill sets.

Exemplary WIP100includes a server102and a database111. Server102includes a managing processor104(e.g. CPU), memory106, hiring functionality107, a display manager108, contract work management functionality109, controller110and a communications interface105for linking the WIP to the internet. WIP display manager108has, in addition to other functions, the function of creating graphical user interfaces on the client devices120a,120betc. within their WIP subscriber accounts. Similar to that for WMS12, WIP hiring functionality107contains business rules for evaluating among different applicants for a particular job to select and hire qualified candidates, and, frequently, further rules for distinguishing among such candidates. Hiring functionality107also contains business rules for evaluating responses from professionals to an RFx and responses from professionals to a statement of work (SOW). Contract work management functionality109contains business rules for managing the necessary fulfillment and alterations of contingent contract jobs and contract SOW engagements.

Database111stores profile data from the subscriber job seekers with accounts. The profile data identifies each professional and represents at least the professional's skills and experience. The profile data for each subscribing professional is made available to subscribing hiring companies that connect to the WIP100over the internet. Database111also stores job opportunities, RFxs and SOWs entered into the WIP by hiring companies. At the same time, job opportunities, RFxs and SOWs that are entered into the WIP by a hiring company are published by the WIP100to be accessible on the plural job seekers' personal client devices120a,120betc. Publication on WIP100routinely identifies the company along with provision of a description of the work opportunity and the required skill set or qualifications. The platform now known as a WIP is relatively new, and up to now, due to the high security protections that hiring companies require for their WMS systems, direct system to system integration to WIPs like WIP100and like talent platforms, has been prohibited—to the detriment of these hiring companies in their searches for qualified workers.

SUMMARY OF THE INVENTION

The present invention provides a fully interconnected system of WMSs used by hiring companies and the disparate WIPs increasingly preferred by job seekers. It vastly increases the pool of talented professionals available to hiring companies with specific needs for contractors and employees by enabling and automating communications between each WMS and the WIPs. To do this, it improves conventional computer-based systems used by hiring companies by configuring them so as to systematically access talent pools available at the WIPs that up to now have been unavailable to them. Yet it accomplishes this without compromising tight security over proprietary data processed by the WMS by providing an intermediary between WIPs accessible over the internet and WMS. The invention thereby enables the hiring companies to use their WMS systems to select from among job seekers and invite selected job seekers who are associated with different WIPs to apply for job opportunities, and to respond to RFxs and SOWs, as they become available. It further enables a hiring company, by use of its WMS, to automate the invitations of talent, negotiation of rates, negotiation of SOWs, onboarding processes, offboarding processes and billing and payment. The invention further contemplates carrying out these automated processes without interrupting the hiring company's customary referral relationships with its authorized talent suppliers.

The invention includes a server configured as a Work Integration Platform that connects multiple WMSs and WIPs, another server configured as a Sourcing Plugin that provides additional sourcing functionality to WMS users, and still another server configured as a Talent Exchange Architecture that is remote from the servers of the Work Integration Platform, each WMS, each WIP and the Sourcing Plugin. The Work Integration Platform has several functions. It has the responsibility of providing WIPs access to API specifications defining a same single array of application programming interfaces (APIs) to be implemented, adopted and hosted by all WIPs so that the WIPs can be called upon by the Work Integration Platform. This array of APIs when implemented and hosted by the selected WIPs gives them membership within a network of WMSs integrated with the Work Integration Platform and the Talent Exchange Architecture according to the invention. These WIP side APIs, when called on by the Work Integration Platform, transfer control over the hiring functionality and contract work management functionality of the WIP to the platform. Further, the same WIP side APIs provide protocols for the member WIPs to receive electronic documents with data originating from a WMS and to send electronic documents with data to a member WMS or to the Talent Exchange Architecture via the Work Integration Platform.

The Work Integration Platform also has the responsibility of providing the WMSs access to API specifications defining a same single array of WMS side APIs to be implemented, adopted and hosted by each WMS so that it can be called by the platform. The APIs of this array when implemented and hosted by a selected WMS similarly gives the WMS membership within the network of WIPs integrated with the Work Integration Platform and the Talent Exchange Architecture. As with the WIP side APIs, the WMS side APIs, when called on by the Work Integration Platform, transfer control over the hiring functionality and contract work management functionality of the WMS to the platform. The WMS side APIs, likewise provide protocols for member WMSs to receive electronic documents with data originating from a WIP and to send electronic documents with data to any member WIP, or to the Talent Exchange Architecture, always via the Work Integration Platform. In the event that there are situations in which preexisting WMS side or WIP side APIs cover some part of necessary functionality outlined in the API specifications of the platform, the platform may implement and adopt, in whole or in part, corresponding API specifications of the WMS or WIP in order to reduce the burden of a WMS or a WIP to become a member.

The Work Integration Platform thus provides a means for each WMS to effectively communicate with multiple WIPs without directly integrating with any WIP. Each participating WMS transfers control of its hiring and contract job management functionality to the Work Integration Platform for the purpose of facilitating the hiring of professionals and the subsequent management of contract work. The platform similarly provides a means for any member WIP to effectively communicate with multiple WMSs without directly integrating with any WMS. Each participating WIP likewise transfers control of its hiring and contract job management functionality to the Work Integration Platform for the purpose of facilitating the hiring of its subscribing job seekers and the subsequent management of contract work obtained by such job seekers.

Further, at the WMS side, protocols and routine sets provided in the Sourcing Plugin enable each WMS to load and embed a novel Sourcing GUI provided by the Sourcing Plugin into the WMS's own GUI suite to be presented to WMS users. The Sourcing Plugin also is configured to assume control over at least part of the hiring functionality of the WMS. It does so also by APIs derived from the Work Integration Platform. The Sourcing Plugin integrates with the WMS GUI suite in order to provide additional features and functionality to the WMS user for the purpose hiring professionals. In a preferred embodiment, the Sourcing Plugin, leveraging the Work Integration Platform and functionality in the Talent Exchange Architecture, thereby selects and controls rules for displaying or hiding profiles of job seekers received from the WIPs, as well as rules for filtering and sorting job seeker profiles, and ultimately extending work opportunities to selected individuals. Also, in a preferred embodiment, the Sourcing Plugin receives control over the entire WMS hiring functionality such that it likewise sets rules for showing and/or hiding traditional suppliers, filtering and sorting suppliers, and releasing work opportunities to the suppliers with requests that the suppliers recommend individual candidates.

The Talent Exchange Architecture can be cloud based. The architecture includes at least a database containing standardized profiles constructed from profile data received from the job seeker subscribers via their respective WIPs. The architecture also includes a database containing standardized data representative of work which contains job opportunities, RFxs and SOWs received from each WMS operating with the Work Integration Platform according to the invention. In this configuration, the WMS calls APIs hosted by the Work Integration Platform when sending data representing a new job opportunity, RFx or SOW, which a hiring company user has entered into the WMS, to the Talent Exchange Architecture. Then the Sourcing Plugin enables the user to effectively search profile data within the personal profile database of the Talent Exchange Architecture, via the Work Integration Platform, for job seekers based upon the user's search criteria. Special logic, also residing within the Talent Exchange Architecture, assists in matching prospective job seekers with job opportunities, RFxs and SOWs. Once job seekers are located, the WMS user can instruct the Sourcing Plugin to communicate a form of engagement data that represents invitations for individuals to apply for the job opportunity or respond to a RFx or SOW directly from their respective member WIPs via their personal electronic devices. Simultaneously, the WMS user can instruct the Sourcing Plugin to release similar engagement data indicative of a new work opportunity to the hiring company's traditional suppliers, whereupon the suppliers also may respond with candidates.

The Work Integration Platform remains the intermediary in the channel of all data communications between the hiring company WMS and the professionals at their respective member WIPs. Such data communications, from the hiring company side, can be of “engagement data” for purposes of rejecting candidates, requesting candidates to interview for requisitioned jobs, extending job offers, initiating and completing onboarding, negotiating a SOW and the like. On the other hand, “engagement data” from the job seeker, that is, from the WIP side, can include responses to a hiring company's requests for an interview, to extension of a job offer, to requests for onboarding, responding to an RFx, negotiating a SOW and the like. The Work Integration Platform remains the intermediary link in the channel of communication between a WMS and each WIP once a contract is in place between a hiring company and a job seeker who has become a contracted worker at the company. That is, the Work Integration Platform remains in the channel of data communication between the hiring company's WMS and the contracted worker's WIP for the transmission and reception of “administration data” representing all aspects of the contract, and any modifications thereto. For instance, from the hiring company side, “administration data” can include requests to alter the timeline of a job, or to terminate it, or company replies to submissions of time sheets, expense reports, requests for payment and the like from contracted workers. From the contracted professional's side, administration data can include the actual submissions of time sheets, expense reports and payment requests as well as responses to contract changes by the company.

The invention also contemplates that no access to the Work Integration Platform or the plugin be granted to any entity outside of each member WMS, member WIPs and the Talent Exchange Architecture.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 3Ais a high level diagram showing a preferred system1configuration according to the invention. The invention introduces new Talent Exchange Architecture200, a “Sourcing Plugin”301, and a Work Integration Platform300that together open and maintain desired new communication paths between at least one hiring company10and one or more of the WIPs over the internet.FIG. 3Auses notations10a,10b, . . .10nfor the multiple hiring companies in the network, notations12a,12b, . . .12nfor their respective WMSs, and notations100a,100b, . . .100mfor the plural WIPs. For simplicity, however, reference usually will be made hereinafter to “WMS12”, “WIP100”, “client device120” and “platform300” whereby such reference can mean the ith WMS of the set of WMSs12a-12n, and likewise the ith WIP of WIPs100a-100nand any of the client devices120a,120b, etc. connecting to a WIP. In the same way the (ith) controller22for the ith WMS, or the (ith) controller110for the ith WIP will be referred to simply as “controller22”, or “controller110” etc. It is emphasized that a potentially large number of WMSs and WIPs will be involved in the network of the invention, and a still larger plurality, likely thousands or millions of job-seeking professionals, could be involved as subscribers on the WIPs.

Work Integration Platform300establishes a network of member WIPs among WIPs100a,100b, . . .100mby offering to preselected WIPs API specifications306S that enable each such selected WIP to opt-in to membership. Platform300likewise establishes a network of member WMSs among WMSs12a,12b, . . .12nby offering to preselected WMSs, API specifications305S that enable each such selected WMS to opt-in to membership. The APIs can be written from specifications305S and306S of platform300in any conventional language such as JASON, XML and the like. In this way platform300, in addition to its function of communication intermediary, acts as a library of API specifications that are offered to WMSs12and WIPs100for network membership. Platform300thereby enables each member WMS12to effectively interface with multiple WIPs via a single set or array of APIs structured according to specification306S instead of an array of APIs corresponding to each different member WIP100. Limitation to a single API array for all WIPs100greatly reduces the complexity and cost of WMS to WIP integration. From the WIP side, the integration platform300likewise enables any member WIP100to effectively interface with multiple WMSs via a single set or array of APIs adhering to specification305S instead of a different API array corresponding to each different WMS to similarly reduce the complexity and cost of WIP to multiple WMS integration.

With reference toFIG. 313now also, API calls are illustrated with reference to platform300. It is to be understood that data transmission could be simultaneous with API calls butFIG. 3Bis intended to show API call directions in the preferred embodiments. API array, hereafter referred to as APIs302, is accessible to member WMSs12for the purpose of calling functionality in Work Integration Platform300in order to interface with any member WIP100and also Talent Exchange Architecture200. Conversely, APIs305are embodied as a broad array of APIs that are implemented, adopted and hosted by each member WMS to allow Work Integration Platform300to assert control over the hiring functionality32and contract work management functionality34of each implementing member WMS12. From the point of view of WIPs100, Work Integration Platform300contains array of APIs303that are accessible to each member WIP for the purpose of calling functionality in the platform in order to effectively interface with any member WMS12and Talent Exchange Architecture200. Then again, conversely, APIs306defined by specification306S are implemented, adopted and hosted by each member WIP100to allow Work Integration Platform300to assert control over the hiring functionality107and contract work management functionality109of each such implementing WIP.

Work Integration Platform300also contains an array of APIs, referred to as APIs304, that are accessible to Sourcing Plugin or “agent”301for the purpose of calling functionality in the platform in order to provide communication capability between the agent and member WMSs, member WIPs and exchange architecture200. Talent Exchange Architecture200itself contains APIs214that makes the architecture accessible to Work Integration Platform300for the purpose of calling functionality in the architecture. For purposes of this discussion, an API “call” originates from a server, referred to as the calling server, which is utilizing an API of another server, referred to as the target server, which implements, adopts and hosts the API specification. The API call by the calling server effectively commands the target server to perform some action or logic. As defined by the target server's API specification, an API call may result in data being returned by the target server to the calling server at the completion of a synchronous API call. An example of a return of data via synchronous API calls is given herein when the Sourcing Plugin301calls APIs304in Work Integration Platform300to obtain matching professionals for a work opportunity, which call causes Work Integration Platform300to call APIs214in Talent Exchange Architecture200to retrieve the matching professional profiles.

Talent exchange architecture200, as also seen in isolation inFIG. 3C, preferably is cloud based and includes a server202having master processor203, controller204, network communications interface205and memory207. Server202has a database hereinafter referred to as the work opportunity depository206, a second database hereinafter called the talent depository208, and a standardization database212. It also is shown as hosting APIs214. Database interface216provides access to depositories206,208, and212. In the preferred embodiment, server computer202also is configured to provide matching logic210, or to have access to such logic.

Sourcing Plugin or agent30, shown in isolation inFIG. 3D, can be embodied as a plugin compatible with each host WMS12. It has a processor307, dedicated hiring functionality309, a network communications interface310, a display manager311and a memory312. In the preferred embodiment, display manager311generates what will be referred to as a “Sourcing GUI”. In the preferred embodiments, the Sourcing GUI is loaded and embedded into to each member WMS12by the WMS display manager26. WMS display manager26passes necessary data to Sourcing Plugin301during loading to advise plugin controller308which contract job opportunity, RFx or SOW on which to operate. Hiring functionality309provides ability for WMS users at stations14to review professionals and suppliers and ultimately invite professionals and suppliers to engage in work. Plugin controller308engages the plugin's hiring functionality309to call APIs of platform300in order to access contract job opportunities, RFxs and SOWs, and respective matching professional profiles contained in architecture200via the platform. In response to calls to APIs304from plugin301, platform300calls APIs214in exchange architecture200to receive engagement data inclusive of such opportunities, RFxs, SOWs, and profiles.

Work Integration Platform, inFIG. 3E, has a master processor313, network communications interface316and memory318. Database interface314provides access to database324which stores WMS and WIP membership data including security credentials. Logic315determines the functional workflow routing across the integrated WMS, WIP and Talent Exchange Architecture system1. Controller320calls the appropriate WMS APIs305, WIP APIs306, and Talent Exchange Architecture APIs214based on logic315. Security322controls authentication, authorization and access to the integration platform300, Sourcing Plugin301, exchange architecture200, member WMSs and member WIPs. Security322thus effectively controls which servers may communicate with each other and controls what types of data may be communicated between them.

FIG. 4is a simplified flow chart illustrating an exemplary opt-in procedure for WIPs100and the communication with architecture200thereafter. In step S10, certain of WIPs100a-100mare selected for membership. A supervisor of each such selected WIP100decides whether to accept membership in the network as offered by architecture200at step S12. If this decision is in the negative, the process ends at step S14. Otherwise, the selected WIP downloads API specification306S from platform300and implements and adopts corresponding APIs306that are operative with the selected WIP in step S16such that communication channels for specified communications can be established between each selected WIP100, platform300and architecture200. Next, in step S18, each selected WIP100transmits the profile data file1010for each of its respective subscriber job seekers, who have authorized such profile data transfer, to architecture200for storage in talent depository208. A preferred profile data file1010depicted inFIG. 3Fincludes each job seeker's professional data representing the professional's name, contact information, job title or titles, prior roles, skills, experience, education, availability, pay rate, and the like in addition to data for identifying the particular WIP from which the file originated. Preferably, the profile data file also contains additional data indicative of the job seeking professional's hobbies, interests, and prior projects. In a preferred embodiment, the profile file also contains still other data representations for the professional's commuting preference, inclination for relocation and the like.

It is expected that the professional profiles1010as published by individuals in their respective WIP accounts often will include widely differing terminology for the same concepts. That is, different job seekers will describe the same sought positions differently. Similarly, they are likely to describe similar skills and/or experiences differently. Hence, when data representing these descriptions are accepted at architecture200, via APIs214, processor203and logic210will cause all profile data in file1010to be compared with the standardized data in database212at step S22, and when necessary use natural language processing and neural networks contained in, or embodied by logic210in step524to determine corresponding standardized data for the profile data. The same standardization process will be applied for abbreviations, synonyms, acronyms, misspellings and the like so that the same terminology and format for profile data will be used in all profile data files stored in talent depository208. Standardized profile data for each job seeking professional thus is stored in talent depository208in step S26whereafter the process ends in step528. The use of standardized profile data enables logic210to perform better matching of profiles to work. The professional profile to work opportunity matching logic contained in logic210improves each member WMSs in system1by providing a consistent matching algorithm across all professional profiles, regardless of the profile's source WIP100. This, in turn, improves each hiring company's ability to hire professionals for work opportunities.

We now consider system security in more detail. Sourcing Plugin301is accessible only to an authorized WMS12. Preferably, Sourcing Plugin301uses both role-based and account-based security models to grant access to its host WMS. In this scenario, each WMS12must be provided with a valid account authorizing it to access the Sourcing Plugin301. In a preferred configuration, OAuth 2.0 is used to grant WMS12system level access. In such configuration, WMS12requests an OAuth 2.0 token from the Work Integration Platform security322by specifying the correct identifier, secret key and OAuth scope. If authentication and authorization is granted, WMS12passes the OAuth token to Sourcing Plugin301in order to load the Sourcing GUI into the WMS's native GUI suite. Further, in this preferred configuration, all data transmissions between each WMS12and platform300, between the Sourcing Plugin301and platform300, architecture200and platform300, and between the each WIP100and platform300rely upon HTTPS and TLS 1.0, or higher versions of either, and utilize OAuth 2.0 for authentication and authorization. Even under this system of authorization, essentially only engagement data pertaining to job opportunities, RFxs and SOWs and administrative data pertaining to management of workers under contract are permitted to be transmitted between WMS12via platform300. All other proprietary company data remains separated in WMS12from data that may be aggregated or shared with job searching professionals and with contractually engaged professionals.

With particular reference again toFIG. 3A, platform300is depicted as communicating with the controller22of each WMS12via APIs305to take over control of at least part of the hiring functionality32and contract work management functionality34. Platform300responds to incoming calls to APIs303from any of the member WIPs and incoming calls to APIs304from Sourcing Plugin301by exercising control over WMS functionalities32and34. Upon transfer of control of functionalities32and34from WMS master controller22to platform300, the platform acts as the intermediary between each WMS12and architecture200, the intermediary between Sourcing Plugin301and each WMS12and as the intermediary between each WMS12and each member WIP100within the network established by the invention. Platform300also is depicted as communicating with the controller110of each WIP100via APIs306to take over control of at least part of the hiring functionality107and contract work management functionality109. Platform300responds to incoming calls to APIs302from any of the member WMSs and incoming calls to APIs304from Sourcing Plugin301by exercising control over WIP functionalities107and109. Upon transfer of control of functionalities107and109from WIP master controller110to platform300, the platform acts as the intermediary between such WIP100and architecture200, the intermediary between Sourcing Plugin301and the WIP, and as the intermediary between such WIP and each member WMS12within the network established by the invention.

A specific example of an action causing transfer of control from WMS controller22to platform300starts with the creation and publication of a new job opportunity by hiring company10. This is independent of activities on WIPs100a-100minitiated by the individual job seekers in their accounts. At the hiring company side, a hiring manager or other user staff member of company10enters at workstation14, work opportunity data representative of each new job into database18a. WMS controller22then can call APIs302on platform300to command the platform to channel transmission of the work opportunity data to architecture200by calling architecture APIs214for processing and storage in work opportunity depository206. Upon receipt of this work opportunity data at architecture200, the architecture's controller204performs data standardization using natural language processing and neural networks contained in logic210and the standardized data contained in database212to determine the corresponding standardized data representing the work opportunity, whereafter the standardized work opportunity data is entered into depository206. Afterwards, a hiring company user operating Sourcing Plugin301can view the work opportunity and traditional suppliers50a-50cin the Sourcing GUI embedded in the WMS GUI suite by plugin301, and subsequently invite the suppliers to submit candidates. The Sourcing GUI attributed to the Sourcing Plugin responds to the WMS user's invitation action causing the controller308to call APIs304on platform300, to which the platform responds by assuming control of WMS hiring functionality32via WMS APIs305in order to release the work opportunity data directly to traditional suppliers50a-50c.

Matching logic210applies algorithms for matching standardized professional profile data transmitted from the multiple member WIPs100with the standardized work opportunity data originating from plural equipped WMS systems12. Logic210quantifies the degrees of similarity between predetermined items of professional data within each professional's personal profile data file1010, and predetermined corresponding items in each work opportunity data file1020. For instance, the professional's education, experience, skills, job title and desired pay rate are quantized and compared with a quantization of stated requirements for each of these items in the work opportunity data. The logic210compares the quantized data from the profile data and from the work opportunity data in order to calculate a probability that job seekers represented in its talent depository208could fulfill the requirements of a given stored work opportunity. Logic210also selectively can quantify additional parameters such as the job seeker's geographical location, relocation preferences, commuting preferences and the like and thus include data indicative of these items in its calculation of the probability. Still further, as part of its probability calculations, matching logic210could take into account the likelihood that a given job seeker could qualify for multiple work opportunities at a same hiring company or even at a different such company. Logic210compares the calculated probability with a threshold match probability to identify each candidate for the work opportunity. The overall match probability could be set, for example, at 90%, which is a composite of each of the probabilities for the data points quantized and compared between the professional profile data and the work opportunity data. In a preferred implementation, matching logic210is embodied by a neural network which receives the work opportunity data and professional profile data as input and generates a list of one or more professionals according to principles of artificial intelligence in order to determine which professional or professionals would be most likely to fulfill the requirements of a given work opportunity. Also, the rules by which matching logic210determines the probabilities are dynamic. That is, they are adjusted as work requirements, skill levels and the like change and improve. Logic210continuously computes the match probabilities between all work opportunities and all professional profiles as they are added or updated in Talent Exchange Architecture200in order to make the computed match probabilities available to Sourcing Plugin301via platform300.

In preferred system1, it now should be understood that WMS12is improved by embedding Sourcing GUI320into the WMS's otherwise native GUIs. Alternatively, other WMS native GUIs could be replaced by GUIs created by system control over WMS display manager26and hiring functionality32.FIG. 5Aassists in showing exemplary graphical user interfaces native to WMS12. These interfaces are created by WMS display manager26, i.e. the display functionality, as controlled by controller22. While front end interface40is only schematically shown inFIG. 5A, it will be apparent to those of ordinary skill that this interface includes messages and controls to prompt WMS user entries for designating a new job opportunity, for entering the necessary skills and experiences for the job opportunity, and for designating other necessary requirements such as needs for background checks, admission/identity badges, security clearances and the like to create a new job opportunity. Work opportunity data representing the new position, and the skills, experience, and necessary requirements therefor in the job opportunity are forwarded to appropriate company management personnel by WMS12for approval. When management approval is given, WMS12calls, platform300APIs302to command the platform to receive the approved work opportunity data created at WMS12and to transmit this data to architecture200via a call from the platform to APIs214whereupon the architecture's controller204standardizes the data by using logic210and accessing database212. The standardized work opportunity data is provided to logic210for comparison of the data to the professional profile data stored in depository208. Meanwhile, the WMS user is now ready to initiate a talent search to fill the approved job opportunity.

FIG. 5Bschematically shows preferred Sourcing GUI320which is a front end interface for hiring company users to view, contact and engage job seekers that could fulfill work opportunities. GUI320provides hiring company users the ability to view, contact and engage traditional suppliers. By being embedded into the WMS GUI suite by control over display manager26, GUI320improves the hiring company user's access to functionality provided by GUI320. Plugin301calls platform APIs304to cause the platform to call architecture APIs214to access work opportunity data and matching professional profile data from architecture200. In a preferred embodiment, display manager311configures GUI320to present multiple professional profiles in rows and columns with fields322showing each professional's skills and qualifications. Preferred interface320prominently shows the match probability calculated by logic210for each candidate in fields324. In the preferred embodiment, GUI320also includes an image field326, which can display a facial image for each professional. In interface320, identification information from selected traditional suppliers also is shown.

Interface320is generated to have a number of user-operational controls, generally328. These controls provide for filtering professional profiles by status such as between preferred profiles and non-preferred profiles. Filtering also is done according to preferred payment arrangements such as accepting professionals as independent contractors, or contractors on a W2form. Controls for filtering by keywords, controls for sorting among profiles by different match percentages, controls for searching by name also are provided, as are controls for selecting all profiles, dismissing a matched profile and saving further action for later. In general, an exemplary, but as one of ordinary skill in the art would understand, non-definitive list of criteria for screening professionals at either the level of matching logic210, or at the hiring company user level at GUI320, includes filtering talent profiles according to name, job title, role, project, skills, keywords, work classification, experience, education, talent availability, commuting preference, relocation preference, desired pay rate, pay rate type, matching percentage, standard key words, standard skills, standard job titles and standard roles.

Hiring managers or like users of hiring company10review the professional profiles on GUI320and make their selection from among the presented professionals. As apparent to those of ordinary skill in the art, a preferred example of GUI controls328also could permit these users to introduce additional keywords and search terms to platform300for purposes of narrowing a search. Platform300transmits these additional profile keywords to matching logic210which, in turn, adjusts the parameters used in its probability calculation, recalculates the matching probabilities and again selects from among the professional profile data files to present a slate of professional profiles for GUI320.

Once hiring company personnel select individual professionals from among the professionals presented on GUI320, they operate interface control328aand thereby instruct platform300via APIs304to send a form of engagement data that we will refer to as invitation data directly to each selected job seeker's account at his or her WIP100via APIs306. Hiring company personnel also are able to select traditional suppliers as presented on GUI320by operating interface control328aand thereby instruct platform300via APIs304to send engagement data as invitation data directly to their WMS via an API call to APIs305of their WMS by the platform.

FIGS. 7A and 7Bare the first in a series of sequence diagrams showing operation incorporating the principles hereinbefore discussed. The data communications depicted in the diagrams are to be understood as accomplished synchronously or asynchronously. Discussions of the sequence diagrams also will refer toFIG. 3Billustrating the role of platform300and the APIs in enabling and directing the communications and their content among each WMS12, each WIP100, and Talent Exchange Architecture200. Further, such discussions will continue to refer toFIGS. 3F, 5A, 5Band SC, and other drawings showing user interfaces that ultimately lead to use of the APIs and platform300.

FIGS. 7A and 7Bshow contract job sourcing. The WMS user selects a particular contract job opportunity in a native WMS GUI. This user action results in a transfer of control from WMS processor22to Sourcing Plugin300, which causes the WMS display manager26to load Sourcing Plugin GUI320for that specific job opportunity. Controller308of plugin301acts to retrieve the desired contract job opportunity by sending data321describing a Contract Job Opportunity1020(FIG. 3F) to platform300by calling APIs304. Platform300responds to the call to APIs304by retrieving data representing Opportunity1020by sending corresponding data322to architecture200by calling architecture APIs214. The API214call commands architecture processor203to respond by using interface216to access database206. Sourcing Plugin301likewise retrieves traditional suppliers by communicating data323describing a collection of Suppliers1250(FIG. 3F) from platform300again via APIs304, which call causes platform300to retrieve suppliers according to data324from the user's WMS12via APIs305. As thereby controlled by platform300, WMS12, retrieves such data by accessing its database18a. The Sourcing Plugin301also retrieves data representative of matching professionals by communicating data325describing a collection of Professional Profiles1010(FIG. 3F). Data325is communicated through the channel through platform300, via APIs304, which when called by Plugin301, causes platform300to retrieve professional profile data according to corresponding data326from architecture200via APIs214. Architecture processor204accesses database208to retrieve as data, the matching professional profiles for the specified contract job opportunity. The plugin's display manager311displays data321,323and325to the WMS user for review.

Sourcing Plugin301presents the professional profiles as user recognizable data in GUI320by which the WMS user considers the professionals presented. Sourcing Plugin301responds to user controls328within GUI320to examine any one of the professionals in more detail, such as by clicking on a professional's image in the interface to enlarge the image and the professional's credentials over a backdrop of other profiles. The user at workstation14can reduce the number of candidates presented in GUI320by inputting keyword data327by interface320controls328at workstation14. Sourcing Plugin300responds to such keyword input by transmitting the keyword input data to platform300with data327avia APIs304to which platform300responds by transmitting data327bto architecture200, via APIs214, whereupon controller202causes logic210to retrieve actual keywords (keyword matches) according to data327bfrom database212. Once the keywords have been selected and presented to the user at GUI320, the user performs a search with user controls328to which Sourcing Plugin301responds by sending search data329representing the user's search criteria to platform300via APIs304. Platform300transmits corresponding search data330to architecture200, via APIs214, whereupon controller204causes logic210to perform comparison processing in accordance with the search criteria, and then returns professional profiles as data from database208. Sourcing Plugin301responds to the professional profile data from architecture200by reconfiguring GUI320presented at workstation14to present a narrowed list of profiles.

Control328ain group328of GUI320permits the WMS user to invite selected professionals to apply for the job opportunity. The user's operation of control328agenerates engagement data in the way of invitation data331(Contract Job Invitation1030FIG. 3F) that Sourcing Plugin301transmits to platform300via APIs304. Platform300transmits corresponding invitation data332(Contract Job Invitation1030FIG. 3F) destined for the one or more WIPs whose subscribers provided the selected professional profiles via calls to APIs306. Platform300accordingly transmits similar invitation engagement data334(Contract Job Invitation1030FIG. 3F) to the user's WMS for the purpose of recording which professional-invitees were invited to apply to the contract job opportunity335. Once professionals that are WIP subscribers have been invited, a notification333of each invitation preferably is displayed on each invitee's account and client device120. The hiring company user is also able to invite suppliers to submit candidates to the contract job opportunity by using control group328awhich causes Sourcing Plugin301to transmit another form of invitation data336to platform300via APIs304. Platform300responds by transmitting corresponding invitation data337. via APIs305, to command WMS12controller22and hiring functionality32to notify the hiring company's traditional suppliers about the option to submit candidates to contract job opportunity335.

FIG. 8depicts action at the WIP side in response to the contract job sourcing actions at the WMS side. For convenience, fromFIG. 8onward, a job-seeking professional-subscriber at his or her WIP will be referred to with reference character5.

InFIG. 8, WIP subscriber (professional)5has been selected by company10for invitation to apply for a new job opportunity sourced as shown inFIGS. 7A and 7B. That is, professional5has received invitation data329at his or her client device120via his or her WIP100. Subscribing professional5thus accesses his or her WIP account by personal device120to find front end GUI410, schematically shown inFIG. 5C. Platform300, by calls to WIP side APIs306, exercises control over WIP hiring functionality107and display management functionality107to populate GUI410with information represented by the transmitted invitation data329from platform300. In the preferred embodiment, WIP100creates and transmits, via calls to APIs303, status data412, indicating that the professional is reviewing or has reviewed the invitation, back to platform300. The API303call commands platform300to transmit corresponding status data413to WMS12via APIs305. Upon receipt of such status data413, WMS12notifies the user by notification414that the invitation is being or has been reviewed. Similarly, as also seen inFIG. 8andFIG. 5C, the professional operates controls422of GUI420, to the rear of interface410, to instruct WIP100to transmit data424(Contract Job Application1040FIG. 3F) indicative of his or her interest with respect to the job to platform300by calling platform APIs303. Platform300responds by transmit transmitting data425(Contract Job Application1040FIG. 3F) to WMS12by calling WMS APIs305, whereupon the platform assumes control over WMS display functionality26to set a status engagement indicator426to indicate that the professional has applied for the job, or alternatively that he or she is not interested in the job. A professional that has applied to a job opportunity will be referred to as a candidate up until the point at which the professional is awarded the contract job.

FIG. 9and rear GUI45(FIG. 5A) relate to data transactions following a candidate's decision to apply to the job at the hiring company side. These transactions are enabled by APIs302and306. When a candidate is rejected, the WMS user operates controls47whereupon WMS12transmits to platform300engagement data332indicating that the candidate's application has been declined. Platform300communicates the declined status directly to the candidate's WIP100so that the WIP, upon receipt of the declined status, can enter the candidate's job application334as declined, and notify the candidate directly by notification335via the candidate's account and personal device120.

On the other hand, as shown inFIG. 10, withFIG. 5A, when hiring company10approves of a particular candidate, the WMS user can operate control52of user interface50to instruct WMS12to transmit data340representing a Contract Job Interview Request1050(FIG. 3F) via APIs302, to platform300. Platform300responds by communicating interview request data341to the candidate's WIP100via APIs306. The candidate's WIP100, in response to receipt of the interview request data341, publishes the interview request on the candidate's account on device120as notification342. Proposed dates and times for the interview request as entered by controls54are included within notification342.FIG. 11, withFIG. 5C, in turn, shows transactions in furtherance of the interview. If a proposed date and time are acceptable to professional5, the candidate agrees to the interview proposal at his or her WIP account by operating controls432of interface430accordingly, whereupon, WIP100transmits data434indicative of the professional's acceptance or decline to platform300via APIs303. Platform300transmits the candidate's interview request decision to WMS12with data communication435via APIs305. Notification436of acceptance or decline is published at work station14of the hiring company WMS.

FIG. 12, andFIG. 5Ashowing rear interface50continue engagement data transactions involved in engagement of professional5. Once a successful engagement interview has been completed, for example, and company10decides to make an offer to candidate5, a company user operates control57causing WMS12to transmit engagement data354representing Contract Job Offer1060(FIG. 3F) to platform300via APIs302. Platform300responds by transmitting the offer data355to the professional's account on WIP100via APIs306. The professional's WIP100responds to receipt of the offer data355by creating a job offer356in electronic form and then posting a notification358of the existence of the offer on the professional's client device120. WIP100makes offer356available on client device120where it can be stored, and if desired printed, to provide the professional with a hard copy of the offer. InFIG. 13, candidate5expresses acceptance or refusal of the contract job offer by operating controls442of GUI440(FIG. 5C) to cause WIP100to transmit data444, indicative of the acceptance or refusal, to platform300via APIs303. Platform300transmits the candidate's offer decision to WMS12with data communication445, via APIs305, for presentation as notification446at WMS work station14.

FIG. 14andFIG. 5Ashow a transaction in which company10elects to withdraw a contract job offer before or after acceptance by the professional by using control62on interface60which causes WMS12to send data364, indicative of the withdrawal, to platform300via APIs302. Platform300transmits data365, via APIs306, to the candidate's WIP100where a notification366of withdrawal is posted to the candidate's account. Similarly, provision is made for a transaction in which professional5can decline a job offer after initial acceptance thereof. InFIG. 15, candidate5, at the candidate's account with rear interface450on device120, operates control452to cause WIP100to generate and transmit, via APIs303, data454to platform300to signal decline of the accepted offer to company10. Platform300accordingly publishes declined offer data455to WMS12, via APIs305, for notification456of the professional's action.

Next,FIG. 16sequences transactions following acceptance of a job request, namely, the initiation of onboarding. Approval for onboarding is given at the work station14via rear interface65(FIG. 5A) and controls67at WMS12, and is transmitted as data374, representing Contract Job Onboarding Requirements1070(FIG. 3F), by WMS12to platform300via APIs302. Platform300transmits data376, via APIs306, to the professional's WIP100which causes WIP100to create onboarding requirements377. WIP100displays a notification378on client device120that the onboarding requirements have been sent. The requirements, presented in electronic form377, are available on client device120at interface460shown inFIG. 5C. Thereafter,FIG. 17depicts the continuation of onboarding from the professional's perspective. Candidate5reviews the onboarding requirements377while presented in GUI460on device120. Candidate5uploads the required documentation462from the client device into WIP100. Thus, if the onboarding documentation is satisfactory, candidate5operates interface controls464to instruct WIP100to transmit data462arepresentative of the uploaded onboarding documents to platform300via APIs303. Platform300transmits data462brepresentative of received onboarding documentation to WMS12, via APIs305, which causes WMS12to store the onboarding documents467.

Engagement data flow thereafter continues withFIG. 18wherein company personnel, having received and reviewed the onboarding documentation467, complete onboarding on interface70with operation of controls72which instruct WMS controller22and hiring functionality32to access database18aand generate a formal contract. Data384representative of an actual contract are provided to platform300via APIs302. Platform300transmits the contract data385, containing Contract Job1080(FIG. 3F), to the professional's WIP100, via APIs306, such that WIP100is controlled to produce an electronic version386of a formal contract represented by the transmitted data384at client device120. Notification388appears at the professional's WIP account to apprise professional5of the created contract386.

The system1of the present invention further contemplates that, from time to time, changes in a contract job may become necessary. Such will be seen fromFIGS. 19-24. The system continues to rely upon platform300as the intermediary for transmissions between each WMS12and each WIP100, which transmissions of “administration data” will be generated as necessary to represent transactions done during the life of a contract job. These transmissions likewise occur over the channels established by APIs302,303,305,306that place platform300between WMS12and WIP100.

First, reference is made toFIG. 6Athat shows another front end WMS GUI500. Interface500offers an exemplary menu of common contract changes. For instance, rear interface510andFIG. 19show an example of amendment of contract job dates. On work station14, the WMS user enters a contract job timeline change request via controls512which cause WMS12to send data514, representing a Contract Job Timeline Change Request1090(FIG. 3F), to platform300. Platform300transmits corresponding data515to the WIP account of a professional under contract via APIs306. WIP100responds to receipt of the transmitted timeline change request data515by registering the change request. creating an electronic version516of a formal change request and posting a notification517therefor in the WIP account of the contracted professional5. In these examples, GUI600is a front end WIP interface apprising the contracted professional5that the professional's company10is requesting a contract change. Rear interface610corresponds to notification517ofFIG. 19. Next,FIG. 20shows review of the timeline change notification request by professional5, and the professional's action at controls612in response. If the contracted professional5agrees to the change, WIP100automatically updates the contract timeline to accommodate the change. In this case, professional5expresses agreement to the timeline change at his or her WIP account by operating controls612of interface610accordingly, whereupon, WIP100transmits data614indicative of the professional's acceptance or decline to platform300via APIs303. Platform300transmits the professional's decision to WMS12with data communication615via APIs305. Notification616of acceptance or decline is caused to be published at work station14of the hiring company WMS.

FIGS. 6A, 6B and 21continue with commonplace transactions originating from change requests.FIG. 21demonstrates data transmission for a request by hiring company10to extend contract work. At work station14, the WMS user accesses rear interface520with controls522to enter a request for contract job extension which causes WMS12to send data524, containing Contract Job Extension Change Request1100(FIG. 3F), to platform300. Platform300transmits data525to the WIP account of a professional under contract via APIs306. WIP100responds to receipt of the transmitted extension change request data525by registering the extension request, creating an electronic version526of the formal extension request and posting a notification528by interface620on the professional's device120to apprise the contracted professional of the request.

As seen fromFIG. 22, professional5reviews the extension request and responds accordingly by accepting or rejecting the request via interface controls622. If the contracted professional5agrees to the extension, WIP100automatically updates the contract timeline to accommodate the extension. The Professional5indicates agreement to the timeline change at his or her WIP account by operating controls622of interface620accordingly, whereupon, WIP100transmits data624indicative of the professional's acceptance (or decline) to platform300via APIs303. Platform300transmits the professional's decision to WMS12with data communication625via APIs305. Notification626of acceptance (or decline) is published at work station14of the hiring company WMS.

FIG. 23depicts action by hiring company10to shorten a contract job. For this administrative data transaction, the WMS user accesses rear interface530and operates controls532to cause WMS12to transmit data534indicative of the hiring company's decision to truncate the job to platform300. Platform300transmits data535to the professional's WIP100to update the contract job end date536and provide for notification538on the professional's device120. At the same time, WIP100registers the new contract end date535. The WMS initiated data transaction ofFIG. 24is similar to that ofFIG. 23. In the preferred embodiments, this transaction also involves WMS interface530and controls532. Here, controls532cause WMS12to transmit data539indicative of the hiring company's decision to terminate the job to platform300. Platform300transmits data540to the professional's WIP100to terminate the contract job541and provide for notification of termination542on the professional's WIP account at the professional's device120.

As is now understood, the networked system of the present invention remains instrumental in administration of an ongoing job, throughout the life of the contract. It further provides for channeling several other species of data pertaining to contract administration between professional5under contract and hiring company10.

FIGS. 3F, 6A, 6B, 25A, 25B and 26illustrate timesheet submissions and review. For timesheet submission, professional5accesses WIP interface630to enter as administrative data634, a particular job, the dates, and the time worked during the job for which the professional wishes to submit a timesheet. In the preferred implementation, interface630provides three distinct sets of controls, a first set632aof search controls for data accessible directly from the professional's WIP100, a second set of632bof search controls for querying WMS12, via platform300and APIs303,305, of the company at which the professional is employed, and a third set632cfor governing actual submission of administrative data representative of a completed timesheet to WMS12. Control set632achannels transmissions of administrative data634only between the contracted professional's personal device120and WIP100. Control set632b, by contrast, causes WIP100to transmit the user entered search criteria data636aindicative of any or all of projects, tasks, pay codes and cost centers to platform300, via APIs303, as data636b. Platform300responds by transmitting data636cto WMS12for matching the search criteria with corresponding project, task, pay code and cost center data stored in WMS database18a. Platform300thereafter receives matching data637(Time Entry Project1120, Time Entry Task1130, Pay Code1140or Cost Center1150) from WMS12and transmits this back to the professional's personal device120via his or her WIP100by using APIs306. Thereafter, the professional completes an electronic version of a timesheet638aand operates controls632cto cause WIP100to transmit data638b(Timesheet1110FIG. 3F) representing the completed timesheet to platform300, via APIs303, with information from the selection of project, task, pay code and cost center data and, if desired, any added comments. Platform300transmits particular administrative data638crepresenting the timesheet to WMS12where data639(Timesheet1110) is presented for review at the company side.FIG. 26, accordingly, shows activity at the company side upon receipt of data representing the submitted timesheet (Timesheet1110). The submitted timesheet (Timesheet1110) is reconstructed in interface540at WMS12for approval or rejection accordingly. Controls542are provided to enable company10to transmit data544indicative of its decision to platform300via APIs302. Platform300responds by transmitting data545to the submitting professional's WIP100. WIP100responds by posting notification546on the professional's device120to advise of approval or rejection of timesheet (Timesheet1110).

FIGS. 3F, 6A, 6B, 27 and 28depict a procedure, similar to that for timesheet construction and submission, for expense reporting. At the contracted professional's side, professional5selects WIP interface640to designate the appropriate contract job at WIP100and enters, as administrative data, necessary expense data643such as the date an expense was incurred, the type of expense, and details of the incurred expense. As with controls632afor timesheet submission, the interface controls642aare between only the professional's personal device120and the professional's WIP100. Control set642b, by contrast, causes WIP100to transmit the user entered search criteria data644aindicative expense type to platform300, via APIs303, as data644b. Platform300responds by transmitting data644cto WMS12for matching the search criteria with corresponding expense type data stored in WMS database18a. Platform300thereafter receives matching data645(Expense Type1170) from WMS12and transmits this back to the professional's personal device120via his or her WIP100using APIs306. Thereafter, the professional completes an electronic version of an expense report646aand operates controls642cwhich causes WIP100to transmit data646b(Expense Report1160) representing the completed report to platform300via APIs303. Platform300responds by transmitting data646cto WMS12where the expense report data647(Expense Report1160) is presented for review at the company side.FIG. 28, accordingly, shows activity at the company side upon receipt of data646crepresenting the submitted expense report647(Expense Report1160). The expense report (Expense Report1160) is reconstructed in interface550at WMS12for approval or rejection accordingly. Controls552are provided to enable company10to transmit data554indicative of its decision to platform300via APIs302. Platform300responds by transmitting data555to the submitting professional's WIP100. WIP100responds by posting notification556on the professional's device120to advise of approval or rejection of expense report (Expense Report1160).

Reference now will be made toFIGS. 29-32, and handling of specific payment requests from the contracted professional in connection with an ongoing or completed contract job. These transactions are similar to that for timesheet and expense report submission.FIGS. 29 and 30illustrate milestone payment requests whileFIGS. 31 and 32pertain to unit of measure payment requests. Each of these payment request processes, as well as other payment request processes known to those of ordinary skill in the art, begins with plural transmissions between only professional5at the professional's client120and the professional's WIP100.

InFIG. 29, professional5uses GUI650to communicate directly with the professional's WIP100and accordingly operates controls652afor entering details related to the milestone payment request. Controls652benable professional5to upload receipts and other documents as attachments564in support of the request. Thereafter, professional5operates controls652cto instruct WIP100to transmit data565, representing Milestone Payment Request1230(FIG. 3F), to platform300via APIs303. Platform300then transmits data566representing the milestone payment request and any supporting documentation to WMS12via APIs305to record the milestone payment request567(Milestone Payment Request1230). Then, as depicted inFIG. 30, the milestone payment request (Milestone Payment Request1230) is reconstructed in interface560at WMS12for approval or rejection accordingly. Controls562are provided to enable company10to transmit data564indicative of its decision to platform300via APIs302. Platform300responds by transmitting data565according to APIs306to the submitting professional's WIP100. WIP100responds by posting notification566on the professional's device120to advise of approval or rejection of milestone payment request (Milestone Payment Request1230).

InFIG. 31, professional5uses GUI660likewise to communicate directly with the professional's WIP100and accordingly operates controls662afor entering details related to a unit of measure payment request. Controls662benable professional5to upload receipts and other documents as attachments574in support of the unit of measure payment request. Thereafter, professional5operates controls662cto instruct WIP100to transmit data575, containing Unit of Measure Payment Request1240(FIG. 3F), to platform300via APIs303. Platform300then transmits data576representing the unit of measure payment request and any supporting documentation to WMS12via APIs305whereupon the WMS records the unit of measure payment request577(Unit of Measure Payment Request1240). Then, as depicted inFIG. 32, the unit of measure payment request (Unit of Measure Payment Request1240) is reconstructed in interface570at WMS12for approval or rejection accordingly. Controls572are provided to enable company10to transmit data574indicative of its decision to platform300via APIs302. Platform300responds by transmitting data575via APIs306to the submitting professional's WIP100. WIP100responds by posting notification576on the professional's device120to advise of approval or rejection of unit of measure payment request (Unit of Measure Payment Request1240).

Next,FIGS. 33 and 40Aillustrate the creation and release of an RFx, (request for information), to selected professionals at their respective WIPs. The WMS user creates RFx713with controls712aon WMS interface710. Controls712benable the WMS user to perform a talent search for qualified professionals in architecture200by transmitting user entered search criteria714aas criteria data714bto platform300via APIs302. Platform300transmits corresponding criteria data714cto architecture200which uses logic210to match professional profiles based on the search criteria and return them as data715(Professional Profile1010FIG. 3F). WMS user selects one or more professionals by using control712cto release the RFx716awhich causes WMS12to transmit RFx data716bto platform300via APIs302. Platform300transmits corresponding RFx data716cto the WIPs of the selected professionals via APIs306. WIP100creates RFx718and notifies the selected professionals on their client devices120concerning the new RFX in notification719.

InFIGS. 34 and 40B, professional5uses WIP GUI810to review the released RFx before deciding to respond. Controls812aare provided to enable professional5to indicate if they are interested or not interested. Controls812acause WIP100to transmit data813a, indicative of the professional's interest, to platform300via APIs303. Platform300transmits data813b, via APIs305, to the WMS12that originated the RFx. The originating WMS12responds by posting notification813con the WMS user's account to indicate the intent of the professional to respond to the RFx.

If the professional is interested in the RFx, advance is made to the process ofFIGS. 35A and 35B. Controls812don interface810permit each professional to respond to general questions directly from their respective client devices120to their respective WIPs100. Milestones can be a part of the selected professional's RFx reply. Through operation of controls812b, each professional can search for milestone types by entering search data816ainto GUI810which causes WIP100to transmit data816bto platform300via APIs303. Platform300transmits corresponding search criteria data816cto WMS12, via APIs305, where milestone types are matched to the search criteria and returned in data817(Milestone Type1210FIG. 3F). Each professional may select a milestone type and enter additional milestone details into GUI810. Units of measure can be a part of the selected professional's RFx reply. Through operation of controls812c, each professional can search and match unit of measure types by entering search data819ainto GUI810which causes WIP100to transmit data819bto platform300via APIs303. Platform300transmits the corresponding search criteria data819cto WMS12, via APIs305, where milestone types are matched to the search criteria and returned in data820(Unit of Measure Type1220FIG. 3F). Each professional may select a unit of measure type and enter additional unit of measure details into GUI810. Control812eenables each professional to submit their RFx response821which causes WIP100to transmit data822, representing the RFx (RFx1180FIG. 3F), to platform300via APIs303. Platform300transmits data823to WMS12, via APIs305, where the RFx response824is submitted before the hiring company user to notify the user of the submitted RFx by notification825.

Next,FIGS. 36 and 40Aillustrate the creation and release of a statement of work (SOW) to selected professionals at their respective WIPs. The WMS user creates SOW723with controls722aon WMS interface720. Controls722benable the WMS user to perform a talent search for qualified professionals in architecture200by transmitting user entered search criteria724aas data724bto platform300via APIs302. Platform300transmits data724cto architecture200which uses logic210to match professional profiles based on the search criteria and return them as profile data725(Professional Profile1010FIG. 3F). WMS user selects on one or more professionals by using controls722cto release the SOW726awhich causes WMS12to transmit data726bindicative of the SOW to platform300via APIs302. Platform300transmits data726cto the WIPs of the selected professionals via APIs306. Each receiving WIP100creates SOW728and notifies the professional on their client device120about the new SOW by notification729.

InFIGS. 37 and 40B, professional5uses WIP GUI830to review the released SOW728before deciding to respond. Controls832aare provided to enable professional5to indicate if they are interested or not interested, and which causes WIP100to transmit data833a, indicative of the professionals interest, to platform300via APIs303. Platform300transmits corresponding data833b, via APIs305, to the WMS12that originated SOW728. WMS12responds by posting notification833con the WMS user's account to indicate the intent of the professional to respond to the SOW.

If the professional is interested in the SOW, advance is made to the process ofFIGS. 38A and 38B. Controls832don interface830permit each professional to respond834to terms directly from their respective client devices120to their respective WIPs100. As with a RFx reply, milestones can be a part of the selected professional's SOW reply. Through operation of controls832b, each professional can search for milestone types by entering search data836ainto GUI830which causes WIP100to transmit data836bto platform300via APIs303. Platform300transmits the search criteria data836cto WMS12, via APIs305, where milestone types are matched to the search criteria and returned in data837(Milestone Type1210FIG. 3F). Each professional may select a milestone type and enter additional milestone details into GUI830. Units of measure838likewise also can be a part of the selected professional's SOW reply. Through operation of controls832c, each professional can search and match unit of measure types by entering search data839ainto GUI830which causes WIP100to transmit data839bto platform300via APIs303. Platform300transmits the search criteria data839cto WMS12, via APIs305, where milestone types are matched to the search criteria and returned in data820(Unit of Measure Type1220FIG. 3F). Each professional may select a unit of measure type and enter additional unit of measure details into GUI830. Control832eenables each professional to submit their SOW response821which causes their respective WIP100to transmit data822representing the SOW (SOW1190FIG. 3F) to platform300via APIs303. Platform300transmits data823to WMS12, via APIs305, where the SOW response is presented824to the hiring company whereupon the company's user is notified about the submitted SOW in notification825.

FIG. 39illustrates further contemplated transactions in the SOW process. Here, hiring company10reviews an electronic SOW document733that was previously submitted by a professional. Thereafter, hiring company10calls upon interface730to signal its intentions via controls732a,732b, and732c. Control732ais operable to cause WMS12to send acceptance data734aas engagement data to platform300via APIs302. Platform300transmits data734bto the submitting professional's WIP100, via APIs306, where the WIP creates the sow based project (SOW Project1200) and notifies the professional with notification735that the SOW has been approved and the project is ready. Alternatively, if hiring company10is not satisfied with all of a professional's responses, controls732bare operated to permit the WMS user to revise the SOW, whereafter controls732care operated to cause WMS12to transmit data738arepresenting the revised SOW to platform300via APIs302. Platform300transmits data738bto the submitting professional's WIP100, via APIs306, where the professional is notified with notification739that the SOW has not been accepted and a revision is available for review.

Before closing, we refer toFIG. 41and return to creation and also updating of personal profiles from the point of view of professional5. The present invention preferably does not disturb the professional's private interactions with his or her WIP and so each professional can establish a professional profile in their WIP100in accordance with their WIP's original WIP-to-client device communication protocols. Professionals who have authorized their respective WIPs to share their profile data with architecture200for purpose of engaging in work, cause their WIP, who is also a member of the network established by the invention, to transfer their profile data after creation901or updating904to platform300as profile data902a,905a(Professional Profile1010FIG. 3F) via APIs303. Platform300transmits corresponding profile data902b,905bto architecture200, via APIs214, where the profile is created903or updated906in database208.

By enabling a fully interconnected system of WMSs12and disparate WIPs100, the invention improves the hiring functionality and contract management functionality contained in each member's WMS server by providing the ability to access, interact with, hire, and manage contract professionals from previously unavailable talent pools without the need to directly integrate with any WIP and without interrupting the hiring company's customary referral relationships with its authorized talent suppliers. The Work Integration Platform controller320and logic315provide additional benefit to the WMS server by abstracting any API differences in Work Integration Platform300and WIP communication for scenarios where, for the Platform, it is chosen to implement any part of a pre-existing WIP API specification that overlaps with APIs303or API specification306S. The Talent Exchange Architecture200, via the Sourcing Plugin301and Work Integration Platform300, further expands the hiring functionality of a member's WMS server by providing the ability to match professionals from multiple member WIPs to work opportunities by the use of the Talent Exchange Architecture's logic210and standardization database212. Conversely the invention improves the hiring functionality and contract management functionality contained in the each member's WIP server by providing the ability to engage in previously unavailable work opportunities from multiple member WMSs and manage their contracts without the need to directly integrate with any WMS. The Work Integration Platform controller320and logic315likewise provide additional benefit to the WIP server by abstracting any API differences in Work Integration Platform and WMS communication for scenarios where, for the Work Integration Platform, it is chosen to implement any part of a pre-existing WMS API specification that overlaps with APIs302or API specification305S. Both API specifications305S and306S define just one set or array of APIs305and306respectively in all member WMSs and in all member WIPs, thus making a most cost-effective way of providing the desired integration through Platform300, Plugin301and Architecture200.

The foregoing embodiments and examples are illustrative rather than restrictive. Those of ordinary skill in the art will appreciate that modifications to the exemplary embodiments may be made without departing from the spirit and the scope of the invention as defined by the following claims.