System for enhancing on-campus communications through vector correlation quantification for employee request submissions

Systems and methods for determining an amount of correlation between non-orthogonal vectors characterizing quantified employee request submissions include generating a prioritization matrix for a request submission including entries associated with characteristics of the request submission considered important by one or more approvers; generating a request attribute vector characterizing attributes of a request extracted from the request submission; calculating a product for each entry of the prioritization matrix by multiplying corresponding entries of the prioritization matrix and the request attribute vector; applying a weighting factor to the product for each entry of the prioritization matrix resulting in weighted products for each entry of the prioritization matrix; accumulating the weighted products into a request quality score indicating an amount of correlation between the prioritization matrix and the request attribute vector; and transmitting an enhanced data packet to another computing device including the request attribute vector, prioritization matrix, or request quality score.

BACKGROUND

Institutions which large numbers of employees, such as universities that have hundreds or thousands of faculty members, are often under a large administration burden when it comes to processing and approving or disapproving employee requests. In some cases, thousands of requests can be submitted within a very short period of time, which makes adequately reviewing the requests and making decisions in a timely fashion very difficult. As recognized by the present inventors, passing data for faculty identification and request submissions can bog down computer networks across a university campus during high-volume and time-intense request submission periods. Also, in dynamic technological industries, economic, government, and university priorities can be constantly changing, which also makes determining whether or not to approve various faculty requests difficult.

The “background” description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description which may not otherwise qualify as conventional art at the time of filing, are neither expressly nor impliedly admitted as conventional art against the present disclosure.

SUMMARY

The implementations described herein are directed toward systems for enhancing on-campus communications through vector correlation quantification for employee request submissions. Also described are systems and methods for determining an amount of correlation between non-orthogonal vectors characterizing quantified employee request submissions including generating a prioritization matrix for a request submission including entries associated with characteristics of the request submission considered important by one or more approvers; generating a request attribute vector characterizing attributes of a request extracted from the request submission; calculating a product for each entry of the prioritization matrix by multiplying corresponding entries of the prioritization matrix and the request attribute vector, applying a weighting factor to the product for each entry of the prioritization matrix resulting in weighted products for each entry of the prioritization matrix; accumulating the weighted products into a request quality score indicating an amount of correlation between the prioritization matrix and the request attribute vector, and transmitting an enhanced data packet to another computing device including the request attribute vector, prioritization matrix, or request quality score.

DETAILED DESCRIPTION

FIG. 1is a diagram of an example environment100for a request management system108, which manages requests submitted by employees, such as researchers or professors at a university. The diagram illustrates a series of interactions between one or more participants and the request management system108which receives requests from requesters102, determines priorities for approving the requests based on national, economic, and/or university interests, ranks the requesters102based on an amount of correlation between the requesters102and the priorities, and determines a suggested decision associated with the submitted requests based on the rankings and/or decisions received from one or more approvers104. In some implementations, the request management system108can also determine a funding amount associated with the request based on current budget allocations, number of requesters, quality of requesters based on a determined request quality score (RQS), and the like. The request management system108may be associated with a particular university or institution, such as an independently operating research lab, government lab or agency, and the like.

In certain embodiments, the request management system108expedites processing and approval of one or more submitted requests by requesters102having a determined RQS that reflects a high correlation between the requester and decision priorities. The RQS is a numerical representation of how well the requester meets predetermined request approval criteria and can be calculated automatically in real-time in response to receiving a submitted request. The request management system108can also provide real-time feedback to the requesters102regarding a likelihood that a particular request will be approved in light of the calculated RQS, historical data related to previous request decisions associated with the requester102or another requester having similar attributes or other similar types of requests.

The requesters102include a plurality of computing devices and databases distributed across a widely dispersed network that may be distributed across a large, international geographic area. The requester network can be separate and independent from any network associated with any other participant in the request management environment100, such as external entities106or approvers104. In some implementations, various processing tasks performed by the request management system108can be distributed to computing resources of the submitter network based on processing demands on the computing resources of the request management system108. In some implementations, the requesters102can include faculty, researches, and other employees of a university.

In addition, the data handled and stored by the requesters102may be in a different format than the data handled and stored by the other participants of in the request management environment100. The requesters102provide inputs to the request management system108that may include request data122provided in a request submission indicating details related to the request such as a type of request, terms of the request, and any other details associated with the request. For example, one type of request can be a sabbatical leave request that can include additional information such as requested dates of sabbatical, sabbatical leave location, suggested replacement faculty member during the sabbatical, and reason for requesting the sabbatical. The data provided to the request management system108from the requesters102may be independent from the other participants and in a different format than the data provided by the external entities106and approvers104.

The approvers104include a plurality of computing devices and databases distributed across a widely dispersed network that may be distributed across a large, international geographic area. The approver network can be separate and independent from any network associated with any other participant in the request management environment100, such as the external entities106or requesters102. In addition, the data handled and stored by the approvers104may be in a different format than the data handled and stored by the other participants of in the request management environment100. In some implementations, various processing tasks performed by the request management system108can be distributed to computing resources of the approver network based on processing demands on the computing resources of the request management system108.

The approvers104can provide inputs to the request management system108that may include prioritization matrix data156that may include ideal request and requester characteristics that are considered to be important by the approvers104when determining whether to approve or disapprove the request. The approvers104can also provide inputs to the request management system108that includes decision data154indicating which requests have been approved or disapproved. In some implementations, the approvers104include university faculty and leadership that are have a stake in the decisions made regarding the requests submitted by the requestors102that can include faculty department heads, deans of colleges, dean of graduate studies, a head and members of a scientific council and various scientific council committees, university administrators, scientific council secretary, secretary of the scientific council, etc. The data provided to the request management system108from the approvers104may be independent from the other participants and in a different format than the data provided by the external entities106and requesters102. In addition, the approvers104can receive data outputs from the request management system108with respect to how the requesters102were ranked with respect to calculated RQS data157.

The external entities106include a plurality of computing devices and databases distributed across a widely dispersed network that may be distributed across a large, international geographic area. The external entity network can be separate and independent from any network associated with any other participant in the request management environment100, such as the requesters102or approvers104. In addition, the data handled and stored by the external entities106may be in a different format than the data handled and stored by the other participants of in the request management environment100. In some implementations, the external entities106may include an independently operating research lab, government lab or agency, a university that is not affiliated with the request management system108, academic professional organization, publication reviewing body, or any other entity that has a stake in the decisions being made by the request management system108. In one example, one or more external entities106can be included in an approval chain for various types of requests, such as publication submission requests or research funding requests. The external entities106provide inputs to the request management system108that may include external source data120such as information regarding funding, publication acceptance, or other types of award decisions that may be made by the external entities106.

In some implementations, the external entities106can also include data sources associated with national, government, and/or economic interests that may affect decisions that are made with respect to the submitted requests. For example, the external entities106can include web servers/databases that contain data associated with job markets and job growth for a particular location, current economic interests of the government, national and international research priorities, and the like. The data provided to the request management system108from the external entities106may be independent from the other participants and in a different format than the data provided by the requesters102or approvers104.

The requesters102, approvers104, external entities106, and data repository114can connect to the request management system108through computing devices158(e.g., mobile device158a, computer158b, or any other type of computing device) via a wired or wireless network (not shown). The network can include one or more networks, such as the Internet and can also communicate via wireless networks such as WI-FI, BLUETOOTH, cellular networks including EDGE, 3G and 4G wireless cellular systems, or any other wireless form of communication that is known.

The request management system108includes one or more engines or modules that perform processes associated with processing incoming requests, collecting data regarding priorities for approving the requests, routing the requests to the approvers104, and approving the requests submitted by the requesters102. References to the engines or modules throughout the disclosure are meant to refer to software processes executed by circuitry of one or more processing circuits, which can also be referred to interchangeably as processing circuitry. In one implementation, the processing circuitry can be included in at least one server.

In one example, a user management engine130includes one or more processes associated with providing an interface to interact with one or more users (e.g., individuals employed by or otherwise associated with the approvers104, requesters102, and/or external entities106) within the request management environment100. The processes performed by the engines of the request management system108can be executed in real-time in order to provide an immediate response to a system input. In addition, the processes can also be performed automatically in response to a process trigger that can include the reception of data from a data repository, a participant, or another processing engine. For example, the user management engine130can control connection and access to the request management system108by the approvers104, requesters102, and external entities106via authentication interfaces at one or more external devices158of the approvers104, requesters102, and external entities106.

The request management system108also includes a data mining/collection engine132that controls the gathering data from the approvers104, requesters102, and external entities106in real-time. In some implementations, the data mining/collection engine132receives data from one or more sources that may have an effect on the generation of a prioritization matrix. The prioritization matrix is used by RQS calculation engine142to calculate the RQS for the requesters102, which indicates the amount of correlation between qualities of the requesters102and the submitted request and the priorities associated with approving or disapproving the requests. For example, the data mining/collection engine132can receive automatically and/or continuously updated data associated with national and international industries that correspond to types of requests received by the request management system108. For example, the data mining and collection engine136can receive automatic updates from government research institutions related to priorities in various research areas that can include types of medical research and other types of science and engineering research.

In addition, the data mining/collection engine132can perform web crawling processes to access the updated data from one or more websites associated with government, economic, and research priorities associated with the external entities106that can be used to determine data entries and weighting factors tar the prioritization matrix that is used to calculate the RQS for the submitted request. In addition, the data mining/collection engine132can receive manually entered information from the participants in the request management environment100, such as the request data122extracted from the electronically-submitted requests as well as request decisions (e.g., approvals or disapprovals) received from the approvers104. The data mining/collection engine132also monitors websites and/or servers that receive and manage biographical information, performance review scores, and teaching/research information associated with the faculty and staff at the university, which are updated as faculty data128stored in data repository114. For example, the faculty data128includes job title, time at university, time in profession, number of students taught by each faculty member, research focus areas, and performance review scores. In addition, the data mining/collection engine132can also determine a number of students associated with a faculty member or professor based on class enrollment lists that are maintained on the websites and/or servers. The data mining/collection engine132can also determine an amount of monetary profit for the university and/or academic department or college that can be attributed to a faculty member due to external research funding grants and other funding sources based on financial information included in various websites or servers.

In addition, the request management system108includes a data management engine134that organizes the data received by the request management system108and also controls data handling during execution of the processes associated with receiving and processing submitted requests, ranking the requesters102based on the calculated RQS associated with a generated prioritization matrix, and routing the requests to the approvers104with automatically generated recommendations for whether to approve or disapprove the request. In some implementations, the data management engine134processes the data received by the data mining/collection engine132and loads extracted data to the request data122, which can be a database of data files of the requests received from the requesters102. In addition, the data management engine134may perform a data validation/normalization process to configure the received requests into a predetermined format compatible with a format of the files of the request data122and ensure that the entries of the received requests have been properly completed.

The data management engine134also controls the interaction of the request management system108with at least one data repository114associated with the request management environment100. For example, the data management engine134can output automatically updated data such as faculty data128and external source data120or manually updated data such as the request data122to the data repository114. The data management engine134can also access any of the data from the data repositories114for use by the request management system108. For example, data generated during the execution of one or more processes by request management system108can also be stored in the data repository114, which can include the prioritization matrix data156, RQS data157, or decision data154. The data management engine134controls the flow of data between the data repository114and the request management system108.

The event trigger engine136manages the flow of data updates to the request management system108. In some implementations, the event trigger data132detects updates to the request data122, faculty data128, prioritization matrix data156, external source data120, or any other type of data collected or controlled by the request management system108. For example, the event trigger engine136detects modifications or additions to the files of the request data122, which may indicate that a new request has been received. When an update is detected to the request data122, the event trigger engine136loads the updated data files to the RQS calculation engine142so that the RQS can be calculated for the submitted request. The event trigger engine136operates in real-time to update the RQS calculation engine142when updated request data122is received from the requesters102. The event trigger engine also operates in real-time to update the prioritization matrix data156in response to the data mining/collection engine132extracting information related to industries and research focuses of the external entities106, which is part of the external source data120. The event trigger engine136also operates in real-time to update the faculty data128in response to the data mining/collection engine132extracting updated biographical information, performance review scores, and teaching/research information of the faculty and staff at the university or updates to the faculty data128that occur as faculty members are hired or leave the university. In addition, the event trigger engine136operates automatically when updated data is detected by the data/mining and collection engine136.

In addition, the event trigger engine136is configured to detect updates to the data stored in the data repository114from the one or more data sources at multiple update velocities. The update velocity of the data corresponds to a rate or frequency at which the request management system108receives data updates from the data sources, such as the faculty data128, external source data120, or request data122. In addition, the velocities with which individual participants provide data updates may also vary. For example, performance review scores that are updated in the faculty data128may be provided for each faculty member to the request management system108at time intervals that correspond to a frequency at which performance reviews are conducted, such as annually. Also, the event trigger engine136can also be configured to detect unscheduled updates to the data stored in the data repository114. For example, case-by-case requests are types of requests that are processed as the requests are received which can be at unpredictable time intervals. For example, sabbatical requests are a type of case-by-case request. The event trigger engine136can be configured to detect multiple scheduled and unscheduled updates from multiple data sources in parallel and in real-time.

The request management system108also includes a request management engine138that processes received request submissions associated with the request management system108. The request management engine138receives requests submitted by the requesters102. The requesters102can submit the requests by accessing a request UI screen output by the GUI engine150through a website, server portal, request interface, and the like. In some aspects, one or more of the data entry fields output to the request UI screen corresponds to the entries of a prioritization matrix as well as a request attribute vector. In addition, access to the request UI screen is controlled by the user management engine130. In response to receiving a submitted request, the request management engine138validates the submitted data and outputting notifications to the requesters102to correct any information in the submitted request that does not conform to predefined criteria for data entry fields of the request and saves the information from the request data entry fields as request data122.

In response to receiving a request, the request management engine138triggers prioritization matrix engine140to generate a prioritization matrix for the request. The preliminary prioritization matrix can include one or more entries associated with biographical characteristics of a potential requester102who may submit a particular type of request, characteristics of the type of request, long-term and short-term achievements of a potential requester who may be considered a good candidate for approval of the type request, and corresponding weighting factors indicating a relative amount of importance for the entries. Details regarding the generation of the prioritization matrix and corresponding weighting factors are discussed further herein.

In response to generating the prioritization matrix, the request management engine138automatically extracts one or more request attributes from the data entry fields of the submitted request and organizes the request attributes into a request attribute vector, which is also stored in the request data122of the data repository114. In some implementations, the extracted request attributes that make up the request attribute vector correspond to the one or more entries of the generated prioritization matrix. For example, the request attribute vector can include entries associated with biographical information of the requester102, achievements of the requester102, as well as information associated with the submitted request. Details regarding the entries of the request attribute vector are discussed further herein.

The request management engine138also triggers the RQS calculation engine142to calculate an RQS for each of the submitted request based on the prioritization matrix by performing a vector overlap process. Details regarding the functionality of the RQS calculation engine142and the vector overlap process are discussed further herein. In response to receiving the calculated RQS for each of the requesters102from the RQS calculation engine142, the request management engine138stores the calculated RQSs as RQS data157in the data repository114and automatically generates an automatic decision prediction, which can be output to the requesters102via a UI screen in real time in response to submitting a request to the request management system108.

In some implementations, the request management engine138determines the decision prediction for a particular request by comparing the RQS of the submitted request to an average RQS for similar types of previously submitted requests. For example, the request management engine138can assign a level of likelihood or probability that the submitted request will be approved based on an amount the calculated RQS for the submitted request exceeds or falls short of the average RQS for a corresponding type of previously submitted request. The levels of likelihood that the submitted request will be approved may include high, medium, and low likelihoods. In some examples, the level of likelihood is represented by a confidence percentage. In addition to outputting the decision prediction to the requester102via a UI, the request management engine138also saves the decision prediction in the data repository114with the corresponding request data122for the requester102.

The request management engine138also determines whether a received request is a case-by-case request or a batch request based on characteristics of the submitted request. In some implementations, case-by-case requests are types of requests that are processed individually as the requests are received and batch requests are types of requests that are processed at predetermined time intervals, which can be referred to as a grouped routing scheme. For example, batch requests may correspond to promotion requests that are processed annually or bi-annually or at another time interval that corresponds to when promotion decisions are made by university leadership. In addition, research funding requests may also be batch requests that are processed at predetermined time intervals that correspond to a beginning or end of a fiscal year when research funds become available for allocation. Award requests for various types of awards (e.g., publishing, research, patent, surgery/performance, teaching, incentive/bonus) can also be classified as batch requests that can be processed when an award application window has closed. Examples of case-by-case requests can include sabbatical leave requests, scientific publication requests, retirement requests, and resignation requests. The request management engine138determines whether or not to flag the request for an individual or grouped routing scheme based on whether the request is a case-by-case request or a batch request. Once the request management engine138determines whether or not to flag the request for an individual routing scheme, request approval engine144is triggered to perform a request routing and approval process, as will be discussed in further detail herein.

The request management system108also includes the prioritization matrix engine140, which automatically generates a prioritization matrix in response to receiving a submitted request. The entries of the prioritization matrix provide an indication of what the approvers104may consider to be important request attributes when deciding whether to approve or disapprove a request and are used to generate the RQS, which is a numerical representation of an amount of correlation between the request attribute vector and the prioritization matrix. The prioritization matrix can include one or more entries associated with biographical characteristics of a potential requester102who may submit a particular type of request, characteristics of the type of request, long-term and short-term achievements of a potential requester who may be considered a good candidate for approval of the type request, and corresponding weighting factors indicating a relative amount of importance for the entries. In some implementations, the prioritization matrix engine140also determines weighting factors for each of the entries of the prioritization matrix that provide an indication of a relative importance of each of the entries. For example, for a request for promotion to associate professor from assistant professor, entries associated with performance review scores and number of years at the university may have higher weighting factors than entries that indicate age or gender of the requester102. As will be discussed further herein, the weighting factors for each entry of the prioritization matrix are used when calculating the RQS for each of the submitted requests.

In response to receiving a request, the prioritization matrix engine140determines whether a prioritization matrix for a corresponding type of request has been generated within a predetermined time period. In some implementations, the prioritization matrix engine140can determine that a previously submitted request corresponds to a current request based on one or more request attributes, such as request type, job title, research/teaching focus, and/or number of years at the university. For example, for a promotion request submitted by an assistant professor assigned to a biomedical engineering department, a corresponding type of previously submitted request may be a promotion request submitted by another professor in the biomedical engineering department two weeks prior to the currently submitted request. In some implementations, for batch requests, the predetermined time period is based on a frequency with which the batch requests are processed. For case-by-case requests, the prioritization matrix engine140may determine the predetermined time period based on how frequently a particular type of case-by-case request is received. For example, if the request management system108typically receives fewer than five sabbatical leave requests within a year, the predetermined time period may be longer than for other types of requests that are submitted more frequently than the sabbatical leave requests.

If a prioritization matrix for the similar type of request has been generated within the predetermined time period, then the prioritization matrix engine140accesses the prioritization matrix and corresponding weighting factors for the corresponding request from prioritization matrix data156in the data repository114, which is as a basis for generating the prioritization matrix for the request currently being processed. If a similar type of request has not been processed within the predetermined time period, then the prioritization matrix engine140generates a default prioritization matrix for the request. In one example, the data repository114stores default prioritization matrices for one or more types of requests as part of the prioritization matrix data156. For example, the prioritization matrix data156can include default prioritization matrices for promotion requests, sabbatical leave requests, various types of award requests, scientific publication requests, research funding requests, retirement requests, resignation requests, and any other type of request that can be submitted by faculty members of a university. In some aspects, the weighting factors for the entries of the default prioritization matrix equal and set to a predetermined value, such as 0.5 in an example where the weighting factors are values between 0 and 1.

In addition, the prioritization matrix engine140triggers data mining/collection engine132to perform web crawling processes to access keyword data and other external source data120from one or more websites associated with government, economic, and research priorities associated with the external entities106. For example, the data mining/collection engine132gathers information related to research priorities in a particular country or region by web crawling through university websites, government research institution websites, etc. and detecting a number of keyword “hits” associated with particular research areas. The keyword data can include words or phrases such as “neurology,” “cardiology,” “biomedical,” “medicine,” and any other words associated with various industries or research areas. The keyword data along with any other extracted data can be stored in the data repository114as the external source data120.

The prioritization matrix engine140uses the keyword data, other external source data120, decision data156, and any other type of data to modify the data entries and weighting factors of the default prioritization matrix or the prioritization matrix associated with a corresponding type of previously submitted request. For example, if the prioritization matrix engine140for a research funding request determines that the corresponding type of previously submitted request favored a particular research area, then the prioritization matrix engine140may reduce the weighting factor associated with that particular research area and increase the weighting factors associated with other research areas increase a diversity of funding allocated to various research areas. Also, if a currently submitted promotion request is submitted by a biomedical engineering faculty data, and the extracted keyword data indicates that biomedical engineering is more popular than chemistry or biology research topics were for previously submitted requests based on the number of keyword hits, then the prioritization matrix engine140may increase the weighting factor for an entry of the prioritization matrix associated biomedical engineering and decrease weighting factors associated with biology and chemistry. The weighting factors for each of the entries of the prioritization matrix can be determined or modified based on inputs received from the approvers104or other staff or administrators of the university or other external entities106.

The request management system108also includes an RQS calculation engine142that calculates the RQS, which is a numerical representation of an amount of correlation between the request attribute vector and the prioritization matrix and provides an indication of how well the submitted requests meet certain criteria associated with approving the request. The RQS calculation engine142performs a vector overlap process, which computes the amount of correlation between the request attribute vector and the prioritization matrix for a particular request. The output of the vector overlap process is sent to the request management engine138, which generates the automatic decision prediction as previously discussed. Details regarding the vector overlap process are discussed further herein. The RQSs calculated by the RQS calculation engine142are stored in the data repository114as the RQS data157.

The request management system108also includes a request approval engine144, which manages a flow of requests or modification request submissions through the one or more approvers104in one or more approval chains. The request approval engine144determines an approval chain for a particular request based on approver data124stored in the data repository114. For example, a neurology publication request may be routed through a neurology department chairman while a chemistry publication request may be routed through a chemistry department chairman.

The request approval engine144determines whether or not the received request has been flagged for the individual routing scheme based on whether the received request is classified as a case-by-case request. If the request was flagged for the individual routing scheme, then the request approval engine144automatically routes the request individually through the approval chain. If the request was not flagged for the individual routing scheme (e.g., a batch request associated with a grouped routing scheme), then the received request remains in a queue until the request window closes. In response to determining that a request window for a particular type of batch requests has closed, the request approval engine144automatically triggers the ranking engine148to rank the received requests for a particular type of request according to the calculated RQS for each requester. In response to receiving a list of ranked requesters from ranking engine148, the request approval engine144routes the requests through the approval chain.

The request approval engine144controls the flow of requests through the approvers104based on the approval chain for a particular request or modification request submission. For example, the approvers104for a particular type of request can include one or more of a faculty department heads, deans of colleges, dean of graduate studies, a head and members of a scientific council and various scientific council committees, university administrators, scientific council secretary, secretary of the scientific council, etc. In some implementations, the approval chain can be based on a job title of the requester102. For example, if the requester102is an associate professor, then an initial approver104in the approval chain is the department head. However, if the requester102is a department head, then an initial approver104in the approval chain may be a college dean.

In some implementations, the request approval engine144triggers the GUI engine150to output an approver interface screen to each of the approvers104as the submitted requests are routed through the approval chain. The approver interface screen is a dashboard that provides the approvers104with various types of data that can include previous decisions for similar types of requests, a history of previous requests made by a particular requester102, a list of requesters for a particular type of requests, etc. The approver user interface screen provides the approvers the ability to approve or disapprove a request for a particular requester and input additional information related to why the approver104approved or disapproved a particular request. The approver user interface screen can also include the decisions by the previous reviewers in the approval chain so that a final approver can make a final request decision based on inputs received from the other approvers104in the approval chain. In some implementations, the decision made by the final approver in the approval chain is the final request decision.

Once the requests have been routed through the approval chain and the decision has been determined, the request approval engine144triggers approved request management engine146to output request approval or disapproval information to the requesters102who submitted the requests. The request approval or disapproval information can be output to the requesters with digital signatures or stamps.

The request management system108also includes an approved request management engine146that controls management of approved requests. In response to receiving the decision associated with a particular request from the request approval engine144, the approved request management engine146outputs approved request information to the requesters102as well as stores the approved request information as decision data154in the data repository114, which can be used in future request cycles to generate the prioritization matrix.

In addition to outputting request approval or disapproval information to the requesters102who submitted requests, the approved request management engine146also manages modification requests in response to receiving a modification request submission for an approved request from a requester102. In some implementations, the requesters102can submit a modification request associated with an approved request to modify one or more terms of the request. For example, the requesters102associated with the approved requests can also submit modification requests to modify a research funding term, increase or decrease a research funding award amount, modify sabbatical leave or retirement dates, etc. In some implementations, the approved request management engine146receives the modification request submission from the GUI engine150. The GUI engine150receives a modification request at a modification request interface screen where the requesters102can input a type of modification request as well as a reason for submitting the modification request.

In response to receiving the modification request submission, the approved request management engine146determines whether the request is within predetermined decision terms that provide for automatic approval of the request. For example, the decision data154for a research funding request may indicate a maximum funding amount for a particular request. If the modification request is to increase a research funding amount to a total amount that is less than the maximum funding amount, then the approved request management engine146outputs a modification approval to the requester and updates the decision data154in the data repository114to indicate that the approval was granted. If the modification request is not within the predetermined decision terms, then the approved request management engine146triggers the request approval engine144to mute the modification request submission through the approval chain to process the modification request submission. For example, the approval chain for the modification request submission is based on the type of modification request being submitted and can include one or more of faculty department heads, deans of colleges, dean of graduate studies, a head and members of a scientific council and various scientific council committees, university administrators, scientific council secretary, and secretary of the scientific council. Once the approved request management engine146receives a final modification decision from the request approval engine144, the final modification decision is output to the requester who initiated the modification request, and the decision data154stored in the data repository114is updated.

The request management system108also includes a ranking engine148that automatically ranks the submitted requests in real-time according to one or more metrics or categories in response to a ranking request from one of the other processing engines. For example, when a batch request window closes, the request approval engine144triggers the ranking engine148to rank a particular type of submitted request from highest to lowest RQS. In other implementations, the ranking engine148can also rank the requesters102according to other metrics such as time at the university, number of publication within the past year, etc.

The request management system108, in some implementations, also includes a graphical user interface (GUI) engine150that controls dissemination and reception of data from the requesters102, approvers104, and external entities106through one or more user interface (UI) screens that are output to the external devices158. For example, the GUI engine150can output a request UI screen to the requesters102who are submitting requests managed by the request management system108. In addition, the GUI engine150can output an approver UI screen which is a dashboard that provides the approvers104with various types of data that can include previous decisions for similar types of requests, a history of previous requests made by a particular requester102, a list of requesters for a particular type of requests, etc. Requesters102who have been decision approvals or disapprovals can submit modification request submissions via a modification request UI screen, which is controlled by the GUI engine150.

The request management system108, in some implementations, also includes a real-time notification engine152that ensures that data input to request management system108is processed in real-time. In addition, the processes executed by the real-time notification engine152ensure interactions between the participants and the request management system108are processed in real-time. For example, the real-time notification engine152outputs alerts and notifications to the approvers104, requesters102, external entities106via the UI screens when a batch request window has open or closed, when a potential requester has submitted a request, when a modification request submission has been received, etc.

In some implementations, data associated with the processes performed by the request management system108is stored in one or more data repositories of the request management environment100such as the data repository114. Data received by the request management system108from the one or more data sources can be received and stored in real-time with respect to when the data is received from the data sources. In addition, the data can be stored automatically in response to receiving one or more data files from the data sources. The data stored in the data repository114can be auto load data that is updated automatically from one or more sources at predetermined time intervals. For example, auto load data can include the faculty data128that is automatically updated from institution registrar databases or external source data120that is received from the external entities106or gathered via web crawling processes.

The data stored in the data repository114can also include manually entered information that is input via UIs at the external devices158and is received by the data mining/collection engine132of the request management system108. The manually entered information can then be then processed by the data management engine134before being disseminated to other processing engines of the request management system108. The manually entered data can include the request data122extracted from the submitted requests and approver data124that indicates the approval chain for the requests.

The data repository114can also store process execution data that is generated by the request management system108when executing the processes associated with, processing and awarding requests, and processing modification request submissions. For example, the process execution data can include decision data154, prioritization matrix data156, and RQS data157.

FIG. 2is an exemplary flowchart of a request management process200, which is controlled by the request management engine138. For example, the request management engine138automatically triggers other processing engines of the request management system108in real-time to perform one or more steps of the request management process200and processes the data received from the other processing engines in accordance with the steps of the process200.

At step202, the request management engine138receives requests submitted by the requesters102. The requesters102can submit the requests by accessing a request UI screen output by the GUI engine150through a website, server portal, request interface, and the like. In some aspects, one or more of the data entry fields output to the request UI screen corresponds to the entries of a prioritization matrix as well as a request attribute vector. In addition, access to the request UI screen is controlled by the user management engine130. In response to receiving a submitted request, the request management engine138validates the submitted data and outputting notifications to the requesters102to correct any information in the submitted request that does not conform to predefined criteria for data entry fields of the request and saves the information from the request data entry fields as request data122.

At step204, in response to receiving a request, the request management engine138triggers prioritization matrix engine140to generate a prioritization matrix for the request. The preliminary prioritization matrix can include one or more entries associated with biographical characteristics of a potential requester102who may submit a particular type of request, characteristics of the type of request, long-term and short-term achievements of a potential requester who may be considered a good candidate for approval of the type request, and corresponding weighting factors indicating a relative amount of importance for the entries. Details regarding the generation of the prioritization matrix and corresponding weighting factors are discussed further herein.

At step206, in response to generating the prioritization matrix, the request management engine138automatically extracts one or more request attributes from the data entry fields of the submitted request and organizes the request attributes into a request attribute vector, which is also stored in the request data122of the data repository114. In some implementations, the extracted request attributes that make up the request attribute vector correspond to the one or more entries of the generated prioritization matrix. For example, the request attribute vector can include entries associated with biographical information of the requester102, achievements of the requester102, as well as information associated with the submitted request. Details regarding the entries of the request attribute vector are discussed further herein.

At step208, the request management engine138triggers the RQS calculation engine142to calculate an RQS for each of the requesters102based on the prioritization matrix by performing a vector overlap process. Details regarding the functionality of the RQS calculation engine142and the vector overlap process are discussed further herein. In response to receiving the calculated RQS for each of the requesters102from the RQS calculation engine142, the request management engine138stores the calculated RQSs as RQS data157in the data repository114.

At step210, the request management engine138determines an automatic decision prediction for a particular request by comparing the RQS of the submitted request to an average RQS for similar types of previously submitted requests. For example, the request management engine138can assign a level of likelihood or probability that the submitted request will be approved based on an amount the calculated RQS for the submitted request exceeds or falls short of the average RQS for a corresponding type of previously submitted request. The levels of likelihood that the submitted request will be approved may include high, medium, and low likelihoods. In some examples, the level of likelihood is represented by a confidence percentage. In addition to outputting the decision prediction to the requester102via a UI, the request management engine138also saves the decision prediction in the data repository114with the corresponding request data122for the requester102.

At step212, the request management engine138also determines whether a received request corresponds to a case-by-case request or a batch request based on characteristics of the submitted request. In some implementations, case-by-case requests are types of requests that are processed individually as the requests are received and batch requests are types of requests that are processed at predetermined time intervals. For example, batch requests may correspond to promotion requests that are processed annually or bi-annually or at another time interval that corresponds to when promotion decisions are made by university leadership. In addition, research funding requests may also be batch requests that are processed at predetermined time intervals that correspond to a beginning or end of a fiscal year when research funds become available for allocation. Award requests for various types of awards (e.g., publishing, research, patent, surgery/performance, teaching, incentive/bonus) can also be classified as batch requests that can be processed when an award application window has closed. Examples of case-by-case requests can include sabbatical leave requests, scientific publication requests, retirement requests, and resignation requests. The request management engine138determines whether or not to flag the request for the individual or grouped routing scheme based on whether the request is a case-by-case request or a batch request.

If the request management engine138determines that the received request is a case-by-case request, resulting in “yes” at step212, then step214is performed where the request data122associated with the case-by-case request is flagged for the individual routing scheme, and then step216is performed. If the request management engine138determines that the received request is a batch request, resulting in a “no” at step212, then the process400proceeds to step216.

At step216, once the request management engine138determines whether or not to flag the request for the individual routing scheme, request approval engine144is triggered to perform a request routing and approval process, as will be discussed in further detail herein.

FIG. 3is an exemplary screenshot of a request UI screen300. The request UI300may be output by the GUI engine150to the requesters102accessing the request UI screen300via a webpage, server portal, etc. The request UI screen300includes multiple data fields and input fields that allow the requesters102to view information related to the type of request they are submitting as well as input the request data122that is extracted from the electronically-submitted request by the request management engine138in response to a selection of submission button312. For example, the GUI engine150outputs a request title to data field302that indicates a type of request the requester102is submitting. At data input field304, the GUI engine150receives biographical information inputs from the requester102that can include name, gender, job title, number of years at university, number of years in profession, research/teaching focus area, etc. At data input field306, the GUI engine150receives historical request information inputs from the requester102that can include number of requests submitted in the past year of the same type, number of requests submitted in the past year of all types, number of requests submitted ever of the same type, number of requests submitted in the past year of all types, previous performance review score, average performance review score, etc. At data input field308, the GUI engine150receives other information inputs from the requester102that can include a personal statement or essay indicating why the requester believes the request should be approved. The request UI screen300can also include other types of input data fields than those described herein. In addition, the request UI screen300includes attachment selection310that when selected, provides the requester with another UI screen where the requester102can attach any additional documentation such as transcripts, recommendation letters, etc. The GUI engine150passes the received inputs to the request management engine138, which are configured into the request attribute vector along with any other information not included in the request attribute vector, which is saved as the requester data122in the data repository114. In some implementations, the data mining/collection engine132can detect the information provided at the request UI300by crawling websites and/or servers that receive and manage biographical information, performance review scores, and teaching/research information associated with the faculty and staff at the university, which is saved in the data repository as faculty data128.

FIG. 4is an exemplary flowchart of a prioritization matrix generation process600, which is controlled by the prioritization matrix engine162. For example, the request management engine138automatically triggers other processing engines of the request management system108in real-time to perform one or more steps of the prioritization matrix generation process600and processes the data received from the other processing engines in accordance with the steps of the process600. The prioritization matrix engine140automatically generates a prioritization matrix in response to receiving a request submission. The entries of the prioritization matrix provide an indication of what the approvers104may consider important request attributes when deciding whether to approve or disapprove a request and are used to generate the RQS, which is a numerical representation of an amount of correlation between the request attribute vector and the prioritization matrix.

At step402, in response to receiving a request, the prioritization matrix engine140determines whether a prioritization matrix for a similar type of request has been generated within a predetermined time period. In some implementations, the prioritization matrix engine140can determine that a previously submitted request corresponds is similar to a current request based on one or more request attributes, such as request type, job title, research/teaching focus, and/or number of years at the university. For example, for a promotion request submitted by an assistant professor assigned to a biomedical engineering department, a corresponding type of previously submitted request may be a promotion request submitted by another professor in the biomedical engineering department two weeks prior to the currently submitted request. In some implementations, for batch requests, the predetermined time period is based on a frequency with which the batch requests are processed. For case-by-case requests, the prioritization matrix engine140may determine the predetermined time period based on how frequently a particular type of case-by-case request is received. For example, if the request management system108typically receives fewer than five sabbatical leave requests within a year, the predetermined time period may be longer than for other types of requests that are submitted more frequently than the sabbatical leave requests. If it is determined that a prioritization matrix for a similar type of request has been generated within a predetermined time period, resulting in a “yes” at step402, then step406is performed. Otherwise, if it is determined that a prioritization matrix for a similar type of request has not been generated within the predetermined time period, resulting in a “no” at step402, then step404is performed.

At step406, if a prioritization matrix for a similar type of request has been generated within the predetermined time period, then the prioritization matrix engine140accesses the prioritization matrix and corresponding weighting factors for the previously submitted request from prioritization matrix data156in the data repository114, which is as a basis for generating the prioritization matrix for a current request.

At step404, if a similar type of request has not been processed within the predetermined time period, then the prioritization matrix engine140generates a default prioritization matrix for the request. In one example, the data repository114stores default prioritization matrices for one or more types of requests as part of the prioritization matrix data156. For example, the prioritization matrix data156can include default prioritization matrices for promotion requests, sabbatical leave requests, various types of award requests, scientific publication requests, research funding requests, retirement requests, resignation requests, and any other type of request that can be submitted by faculty members of a university. In some aspects, the weighting factors for the entries of the default prioritization matrix equal and set to a predetermined value, such as 0.5 in an example where the weighting factors are values between 0 and 1.

At step408, the prioritization matrix engine140triggers data mining/collection engine132to perform web crawling processes to access keyword data and other external source data120from one or more websites associated with government, economic, and research priorities associated with the external entities106. For example, the data mining/collection engine132gathers information related to research priorities in a particular country or region by web crawling through university websites, government research institution websites, etc. and detecting a number of keyword “hits” associated with particular research areas. The keyword data can include words or phrases such as “neurology,” “cardiology,” “biomedical,” “medicine,” and any other words associated with various industries or research areas. The keyword data along with any other extracted data can be stored in the data repository114as the external source data120.

At step410, the prioritization matrix engine140uses the keyword data, other external source data120, decision data156, and any other type of data to update and/or modify the data entries and weighting factors of the default prioritization matrix or the prioritization matrix associated with a corresponding type of previously submitted request. For example, if the prioritization matrix engine140for a research funding request determines that the corresponding type of previously submitted request favored a particular research area, then the prioritization matrix engine140may reduce the weighting factor associated with that particular research area and increase the weighting factors associated with other research areas increase a diversity of funding allocated to various research areas. Also, if a currently submitted promotion request is submitted by a biomedical engineering faculty data, and the extracted keyword data indicates that biomedical engineering is more popular than chemistry or biology research topics were for previously submitted requests based on the number of keyword hits, then the prioritization matrix engine140may increase the weighting factor for an entry of the prioritization matrix associated biomedical engineering and decrease weighting factors associated with biology and chemistry. The weighting factors for each of the entries of the prioritization matrix can be determined or modified based on inputs received from the approvers104or other staff or administrators of the university or other external entities106.

FIG. 5is a data structure of a request attribute vector made that includes the faculty data128that is used to characterize a submitted request in the request management process200. Each of the different components, which will soon be discussed, is used to characterize the constituent components. The request attributes may vary depending on the entries of the prioritization matrix for the associated request. Moreover, the constituent components of the request attribute vector are shown inFIG. 5, and one example of the components of the corresponding prioritization matrix is shown inFIG. 6.

With regard toFIG. 5, each of the components will now be discussed with respect to typical attributes that can be part of the request attribute vector. Attribute508, A1, relates to an age of a requester. The values for attribute A1 range between 0 and 1, and an example breakdown of how the values are mapped is shown in TABLE 1. While the values are shown to range between 0 and 1, this has been done as a matter of convenience to normalize the impact of each attribute. Other ranges of values may be used as well, perhaps even without each attribute having a same range so that some attributes may be weighted more heavily than others.

Attribute510, A2, includes gender of the requester. Example values for A2 are shown in TABLE 2 below.

Attribute512, A3, includes a job title of a requester, which can be indicated as a actual name of a job title or an identification code for the job title. Example values for A3 are shown in TABLE 3 below.

Attribute514, A4, includes an amount of time the requester has been employed at the university. Example values for A4 are shown in TABLE 4 below.

Attribute516, A5, includes an amount of time the requester has been in his or her designated profession. Example values for A5 are shown in TABLE 5 below.

Attribute518, A6, indicates a number of students associated with the faculty member/professor, which can include students taught and/or mentored by the faculty member. In some implementations, the data mining/collection engine132can determine the number of students associated with a faculty member or professor based on class enrollment lists that are maintained on the websites and/or servers. Examples for A6 are shown in TABLE 7 below.

TABLE 6REQUESTVALUEATTRIBUTE# students associated with professorRange 0 to 1A6, 518<50051-1000.25100-5000.75>5001

Attribute520, A7, includes an amount of monetary profit attributed to a faculty member submitting a request. In some implementations, the data mining/collection engine132can determine an amount of monetary profit for the university and/or academic department or college that can be attributed to a faculty member due to external research funding grants and other funding sources based on financial information included in various websites or servers. Examples for A7 are shown in TABLE 7 below.

Attributes508,510,512,514,516,518, and520are biographical components of the request attribute vector that provide basic biographical information about the requester. These components of the request attribute vector are referred to as biographical components502.

Attribute522, A8, includes a type of request. Examples for A8 are shown in TABLE 8 below.

Attribute524, A9, includes a research/teaching focus area of the requester102within. Examples for A9 are shown in TABLE 9 below.

Attributes522and524are request type components of the request attribute vector that provide information about the type of request that has been submitted. These components of the request attribute vector are referred to as request type components504.

Attribute526, A10, includes a number of submitted requests within the past year by the requester that have a corresponding request type to a currently submitted request. Examples for A10 are shown in TABLE 10 below.

TABLE 10REQUESTVALUEATTRIBUTENumber of requests in past year (type)Range 0 to 1A10, 526001-2.353-5.556-10.75>101

Attribute528, A11, includes a total number of all types of submitted requests within the past year by the requester. Examples for A11 are shown in TABLE 11 below.

TABLE 11REQUESTVALUEATTRIBUTENumber of requests in past year (all)Range 0 to 1A11, 528001-2.253-5.506-10.75>101

Attribute530, A12, includes a number of published works for the requester within the past year. Examples for A12 are shown in TABLE 12 below.

TABLE 12REQUESTVALUEATTRIBUTE# publications in past yearRange 0 to 1A12, 530001-2.253-5.506-10.75>101

Attribute532, A13, includes a previous performance review score for the requester. In some implementations, the performance review score is a numeric value in a range from 0 to 100 but can also be a value in another numerical range, such as 0.0-4.0, 0-5, etc. Examples for A13 are shown in TABLE 13 below.

Attributes526,528,530, and532are short-term components506of the request attribute vector that provide information a requester's recent performance and interactions with the request management system108.

Attribute534, A14, includes a total number of submitted requests ever submitted by the requester that have a corresponding request type to a currently submitted request. Examples for A14 are shown in TABLE 14 below.

TABLE 14REQUESTVALUEATTRIBUTENumber of requests ever (type)Ranee 0 to 1A14, 534001-10.3511-20.5521-25.75>251

Attribute536, A15, includes a total number of all types of requests that ever been submitted by the requester. Examples for A15 are shown in TABLE 15 below.

TABLE 15REQUESTVALUEATTRIBUTENumber of requests ever (all)Range 0 to 1A15, 536001-10.2511-20.5021-25.75>251

Attribute538, A16, includes a total number of works authored by the requester that have ever been published. Examples for A16 are shown in TABLE 16 below.

Attribute540, A17, includes an average performance review score for the requester for all performance reviews the requester has ever received. In some implementations, the performance review score is a numeric value in a range from 0 to 100 but can also be a value in another numerical range, such as 0.0-4.0, 0-5, etc. Examples for A17 are shown in TABLE 17 below.

Attributes534,536,538, and540are long-term components507of the request attribute vector that provide information a requester's performance and interactions with the request management system108over an entire length of a requester's employment by the university.

The request attribute vector can also include other components instead of or in addition to the entries described herein. The expansion attributes can be categorized under the biographical components502, request type components504, short-term components506, or long-term components507. These too would have exemplary value ranges between 0 and 1.

FIG. 6is a data structure of a prioritization matrix with entries that provide an indication of what the approvers104may consider to be important request attributes when deciding whether to approve or disapprove requests and are used to generate the RQS. According to some aspects, the components of the prioritization matrix may be of the same type and number as the components of the request attribute vector ofFIG. 5.

Attribute608, P1, relates to an age of a requester. Example values for P1 are shown in TABLE 18.

Attribute610, P2, includes gender of the requester. Example values for P2 are shown in TABLE 19 below.

Attribute612, P3, includes a job title of a requester, which can be indicated as a actual name of a job title or an identification code for the job title. Example values for P3 are shown in TABLE 20 below.

Attribute614, P4, includes an amount of time the requester has been employed at the university. Example values for P4 are shown in TABLE 21 below.

Attribute616, P5, includes an amount of time the requester has been in his or her designated profession. Example values for P5 are shown in TABLE 22 below.

Attribute618, P6, indicates a number of students associated with the faculty member/professor, which can include students taught and/or mentored by the faculty member. In some implementations, the data mining/collection engine132can determine the number of students associated with a faculty member or professor based on class enrollment lists that are maintained on the websites and/or servers. Examples for P6 are shown in TABLE 23 below.

TABLE 23VALUEENTRY# students associated with professorRange 0 to 1P6, 618<50051-1000.25100-5000.75>5001

Attribute620, P7, includes an amount of monetary profit attributed to a faculty member submitting a request. In some implementations, the data mining/collection engine132can determine an amount of monetary profit for the university and/or academic department or college that can be attributed to a faculty member due to external research funding grants and other funding sources based on financial information included in various websites or servers. Examples for P7 are shown in TABLE 24 below.

Attributes608,610,612,614,616,618, and620are biographical components of the prioritization matrix that provide basic biographical information about the requester. These components of the prioritization matrix are referred to as biographical components602.

Attribute622, P8, includes a type of request. Examples for P8 are shown in TABLE 25 below.

Attribute624, P9, includes a research/teaching focus area of the requester102within. Examples for P9 are shown in TABLE 26 below.

Attributes622and624are request type components of the prioritization matrix that provide information about the type of request that has been submitted. These components of the prioritization matrix are referred to as request type components604.

Attribute626, P10, includes a number of submitted requests within the past year by the requester that have a corresponding request type to a currently submitted request. Examples for P10 are shown in TABLE 27 below.

TABLE 27VALUEENTRYNumber of requests in past year (type)Range 0 to 1P10, 626001-2.353-5.556-10.75>101

Attribute628, P11, includes a total number of all types of submitted requests within the past year by the requester. Examples for P11 are shown in TABLE 28 below.

TABLE 28VALUEENTRYNumber of requests in past year (all)Range 0 to 1P11, 628001-2.253-5.506-10.75>101

Attribute630, P12, includes a number of published works for the requester within the past year. Examples for P12 are shown in TABLE 29 below.

TABLE 29VALUEENTRY# publications in past yearRange 0 to 1P12, 630001-2.253-5.506-10.75>101

Attribute632, P13, includes a previous performance review score for the requester. In some implementations, the performance review score is a numeric value in a range from 0 to 100 but can also be a value in another numerical range, such as 0.0-4.0, 0-5, etc. Examples for P13 are shown in TABLE 30 below.

Attributes626,628,630, and632are short-term components606of the prioritization matrix that provide information a requester's recent performance and interactions with the request management system108.

Attribute634, P14, includes a total number of submitted requests ever submitted by the requester that have a corresponding request type to a currently submitted request. Examples for P14 are shown in TABLE 31 below.

TABLE 31VALUEENTRYNumber of requests ever (type)Range 0 to 1P14, 634001-10.3511-20.5521-25.75>251

Attribute636, P15, includes a total number of all types of requests that ever been submitted by the requester. Examples for P15 are shown in TABLE 32 below.

TABLE 32VALUEENTRYNumber of requests ever (all)Range 0 to 1P15, 636001-10.2511-20.5021-25.75>251

Attribute638, P16, includes a total number of works authored by the requester that have ever been published. Examples for P16 are shown in TABLE 33 below.

Attribute640, P17, includes an average performance review score for the requester for all performance reviews the requester has ever received. In some implementations, the performance review score is a numeric value in a range from 0 to 100 but can also be a value in another numerical range, such as 0.0-4.0.0-5, etc. Examples for P17 are shown in TABLE 34 below.

Attributes634,636,638, and640are long-term components607of the prioritization matrix that provide information a requester's performance and interactions with the request management system108over an entire length of a requester's employment by the university.

The prioritization matrix can also include other components instead of or in addition to the entries described herein. The expansion entries can be categorized under the biographical components602, request type components604, short-term components606, or long-term components607. These too would have exemplary value ranges between 0 and 1.

Next,FIG. 7is a graph of a request attribute vector and a prioritization matrix in two dimensional space, according to certain embodiments. As seen, the request attribute vector, A, may reflect some but not all of the attributes covered by one particular prioritization matrix, P. If this is the case, the magnitude of the projection vector of the request attribute vector, A, onto the prioritization matrix, P, may indicate an amount of commonality between the two vectors. Accordingly, the RQS calculated by the RQS calculation engine142is a numerical representation of the commonality between the request attribute vector, A, and the prioritization matrix, P.

Although there are different axes x and y shown, these axes are not necessarily orthogonal, but instead have some attributes in one of the vectors (A or P) that are correlated with other attributes in other vectors. Nevertheless, in order to identify how a set of request attribute data maps into the two domains, a mapping process is performed to see how the request attribute vector maps onto one or more prioritization matrices. The magnitude of the vectors along each axis is a function of the additive values of the attributes that make up the vector. For example, in the request attribute vector, the range of values of an amount of time at the university may be 0.00 to 50.00, for example. The maximum contribution to the magnitude of the A vector is if the request has the same amount of time at the university as the amount of time at the university entry in the corresponding prioritization matrix. This particular attribute (amount of time at the university) can then be weighted based on a weighting table (as will be discussed) to help normalize the amount of contribution that attribute may have relative to other attributes that make up the vector.

FIG. 8is a graphical illustration of how pairs of vectors (P, A) are compared to one another to arrive at a determination of an amount of commonality between the two vectors (e.g., the RQS), according to certain embodiments.FIG. 8includes vector A800with exemplary weighted attributes w1aA1802, w2aA2804, and wnaAn806(the weights are shown for brevity in the Figure as w), although other weighted attributes would be included in the process. The respective weights are set based on the query that is made based on the request data122extracted from the submitted request. Vector P808includes similar weighted attributes, such as w1pP1. Weighting the attributes adjusts the spatial size associated with that particular attribute, thus affecting the potential size of the correlation graph for that particular vector (e.g., it affects how big the A shape is on the correlation vector, for example). Weighting the correlation calculations adjusts the relative contributions each pair of components (e.g., A1,P1) contributes to an overlap area in the correlation graph (e.g., the projection of the A vector onto the P vector).

In a first multiplication step, w1aA11002is multiplied with w1pP1810, and the product is multiplied by a correlation weight C1 and the result sent to an accumulator (summation device)812. The correlation weight C1 is a coefficient that adjusts the level of relevance for the matching pair for the query made. The products from the other matching pairs of weighted components from the vectors are multiplied (e.g., w2aA2×w2pP2 . . . wnaAn×wnpPn), adjusted by their respective correlation weight (Cx, x being an index), and summed in the accumulator812. Then the weighted attributes in one vector (vector A800in this example) are shifted left814by one position and then then are multiplied by the corresponding weighted attribute in vector P808and correlation weight C2. For example, in the second step w2aA2804is multiplied by w1pP1810and the product is multiplied by a correlation weight Cx and the result is summed with the other products in the accumulator812. The one exception is that the left most weighted attribute (which in this case is w1aA1) is circular shifted right816so as to take the position of wnaAn806. This process continues until all of the weighted attributes of one vector are multiplied, adjusted by a correlation weight, and summed with all the other attributes of the other vector.

With regard to the weights, each attribute of each vector is first weighted such that each attribute is either weighted with a 0 or a value between zero and 1. A zero value means that the subject attribute does not contribute at all. Values closer to 1 are deemed to be associated with attributes that have a higher relevance toward attributes of an ideal candidate receiving a request approval. Each attribute of each vector is then combined (multiplied in this example, but could also be added or combined in another mathematical fashion) with each attribute of the other vectors, and a resultant sum is obtained. The weighted vector correlation of the A and P vectors results in the overlap area of the two vectors.

While in the above-described embodiment, there a fixed weight is assigned to each attribute for each vector. However, for an even more refined correlation process, a separate weight is applied for each attribute for each multiplication performed. For example, there may be a high correlation between a requester who has a high well-roundedness score and the quality of the requester. However, there may be little correlation weight for the ethnicity or hometown of the requester.

Each query will have a relevant subset of weights for each vector (signifying the contribution of each particular attribute to each vector space in the correlation graph (e.g., the size of region A). Furthermore the correlation between the two spaces (e.g., between A and P) is influenced by the weight of the correlation of each pair of vector attributes (e.g., A1, P1) for that particular query. The tables below include the attribute weights and correlation weights for a request. For any weight or coefficient not particularly provided for, its value is set at 0.5, although it may be changed to any value ranging between 0 and 1.

Attribute Weight table for a biomedical engineering research funding request.

A vector Correlation Coefficient Table for P regarding the biomedical engineering research funding request.

This process of identifying attributes, weights and correlation coefficients may be applied to other A-P correlation space analyses for different prioritization matrices as well as other database queries. Similar weight and coefficient tables are stored for other types of requests managed by the request management system108.

Next,FIG. 9is a flowchart of a vector overlap process900for determining the overlap amounts for the request attribute vector and the prioritization matrix for a particular request, according to certain embodiments. The vector overlap process900is controlled by the RQS calculation engine142. For example, the RQS calculation engine142automatically triggers other processing engines of the request management system108in real-time to perform one or more steps of the vector overlap process900and processes the data received from the other processing engines in accordance with the steps of the process900. The RQS calculation engine142automatically calculates the RQS for a requester102in response to the generation of a request attribute vector by the request management engine138.

The process begins at step901where the RQS calculation engine142stores the prioritization matrix for the request in a first correlation register and the request attribute vector for the requester102in a second correlation register.

At step902where each of the entries of the prioritization matrix has a weight applied thereto. The weights are stored in a memory table of the prioritization data156with the corresponding prioritization matrix. The process then proceeds to step904where pairs of weighted adjacent entries of the prioritization matrix and request attribute vector are multiplied with each other, and then in906the products of all the multiplications are accumulated. Then in step908a query is made regarding whether all the pairs of entries have been multiplied. If the response to the query is negative, the process proceeds to step910where the attributes in one vector are circular shifted and the process then returns to step904. However, if the response to the query in step908is affirmative, the process proceeds to912, where the cumulative output is produced and used for graphical analysis. The value that is output is fraction of the total overlap if the max weight is applied to the max value of all attributes for all vectors and the correlation is performed on that maximum condition. Moreover, the output that is produced at step912can be a percentage of the maximum possible overlap space for the request attribute vector and the different component prioritization matrices.

The output produced at step912corresponds to the RQS is then sent to the request management engine138, which generates the automatic decision prediction as previously discussed.

FIG. 10is an exemplary flowchart of a request approval process1200. The request approval process1000is controlled by the request approval engine144, which automatically triggers other processing engines of the request management system108in real-time to perform one or more steps of the request approval process1000and processes the data received from the other processing engines in accordance with the steps of the process1000.

At step1002, the request approval engine144determines whether or not the received request has been flagged for the individual routing scheme based on whether or not the request is classified as a case-by-case request. If the request was flagged for the individual routing scheme, resulting in a “yes” at step1002, then the process continues to step1008, and the request approval engine144automatically routes the request through the approval chain. If the request was flagged for the grouped routing scheme (e.g., a batch request), resulting in a “no” at step1002, then the process proceeds to step1004.

At step1004, the request approval engine144determines whether a batch request window has closed. In some implementations, submitted batch requests remain in a queue until a batch request window closes. If the batch request window has closed, resulting in a “yes” at step1004, then step1006is performed. Otherwise, if the batch request window has not closed, resulting in a “no” at step1004, then the process returns to step1002.

At step1006, in response to determining that the batch request window has closed, the request approval engine144automatically triggers the ranking engine148to rank the received requests for a particular type of request according to the calculated RQS for each submitted request.

At step1008, in response to receiving the ranked requests from the ranking engine148or in response to receiving a request that is flagged for the individual routing scheme, the request approval engine144routes the requests through the approval chain by performing a request routing process. Details regarding the request routing process are discussed further herein.

At step1010, once the requests have been routed through the approval chain and decisions have been determined, the request approval engine144triggers approved request management engine146to output request approval or disapproval information to the requesters102associated with the decision. The request approval or disapproval information can be output to the requesters with digital signatures or stamps. The approved request management engine146also stores the approved request information as decision data154in the data repository114, which can be used in future requests to generate the prioritization matrix.

FIG. 11is an exemplary flowchart of a request routing process1100. The request routing process1100is controlled by the request approval engine144, which automatically triggers other processing engines of the request management system108in real-time to perform one or more steps of the request routing process1100and processes the data received from the other processing engines in accordance with the steps of the process1100.

At step1102, the request approval engine144determines an approval chain for a particular request based on approver data124stored in the data repository114. For example, the approvers104for a particular type of request can include one or more of faculty department heads, deans of colleges, dean of graduate studies, a head and members of a scientific council and various scientific council committees, university administrators, scientific council secretary, secretary of the scientific council, etc. In some implementations, the approval chain can be based on a job title of the requester102. For example, if the requester102is an associate professor, then an initial approver104in the approval chain is the department head. However, if the requester102is a department head, then an initial approver104in the approval chain may be a college dean.

At step1104, the request approval engine144routes the requests for a particular request to a next approver in the approval chain. The approver interface screen is a dashboard that provides the approvers104with various types of data that can include previous decisions for similar types of requests, a history of previous requests submissions by a particular requester102, a list of requesters for a particular type of requests, etc.

At step1106, the request approval engine144receives the decision from the approver104. The approver user interface screen provides the approvers the ability to approve or disapprove a request for a particular requester and input additional information related to why the approver104approved or disapproved a particular request. The approver user interface screen can also include the decisions by the previous reviewers in the approval chain so that a final approver can make a final request decision based on inputs received from the other approvers104in the approval chain. In some implementations, the decision made by the final approver in the approval chain is the final request decision.

At step1108, the request approval engine144determines whether or not there is another approver in the approval chain. If a current approver is not the final approver, resulting in a “yes” at step1108, then the process proceeds to step1104to route the requests to the next approver in the approval chain. If the current approver is the final approver, resulting in a “no” at step1108, then the process is terminated.

FIG. 12is an exemplary screenshot of an approver UI screen1200. The approver UI screen1200may be output by the GUI engine150to the approvers104in the approval chain for a particular type of request. The approver UI screen1200includes multiple data fields and input fields that allow approvers104to view information related to the submitted requests and the corresponding requesters102. A request identification tab1202indicates which type of request the approver104is viewing. For example, the request tab1202can include the type of request and corresponding details along with a serial number that uniquely identifies the type of request, such as a neurology research award as shown inFIG. 12. In some implementations where the approver104is in the approval chain for multiple requests, the approver UI screen can include multiple request identification tabs1202associated with each of the types of requests that can be selected by the approver.

At data input field1206of the approver UI screen1200, the GUI engine150outputs a list of the requesters102who have submitted a particular type of request along with an identification number and the corresponding RQS that was calculated for the requester by the RQS calculation engine142. The approver104can select a requester1208from the data input field1206, and in response, the GUI engine150outputs a request decision field1210where the approver104can view the submitted request and indicate a recommendation of whether or not to approve the request along with a recommended funding amount, if applicable.

At data field1204, the GUI engine150outputs previous request submissions made by a particular requester over a period of time, which may aid the approvers104in making request decisions. For example, the data field1204shows that the requester1208selected at data field1206submitted a research funding request in2012, a promotion request in2013, a teaching award request in2014, a research funding request in2015, and a publication request in2016. In some implementations, in response to receiving a selection of a previous request submission, the GUI engine150outputs additional information to the approver104associated with the previous request submission.

At data field1212, the GUI engine150provides previous decision statistics for various types of requests. For example, the data field1212allows the approver104to select a year, request type, and additional request details in order to provide filtered previous decision statistics that may aid the approver104in deciding whether to approve or disapprove the request.

FIG. 13is an exemplary illustration of a portion of the request management environment that includes computing resources of a processing engine, such as request approval engine1331and computing resources of an approver network1304that presents the approver UI screens to computing devices1358of the approvers104. In some implementations, the network1304can also represent the approver network or the external entity network. In some implementations, the computing resources of the approver network1304can be configured to perform various processes associated with the request management system108, such as the request routing process1100(FIG. 11).

In one example, in response to determining that an amount of network or processing congestion of at computing resources of the request approval engine1331is greater than a predetermined threshold, the request approval engine1331may transmit a processing resource query1326to the computing resources of other networks connected to the request management system108, such as the approver network1304, requester network, and/or external entity network. In response to transmitting the processing resource query to the computing resources of the other networks, the request approval engine1331receives processing capability response messages1328from the other networks indicating processing capabilities of the associated computing resources. Based on the processing capabilities of the computing resources associated with the connected networks, the request approval engine1331selects the network to allocate processing resources from in order to reduce the processing burden on the request approval engine1331. In one example, the request approval engine1331selects the computing resources from the connected network that has a greatest processing capacity. In other implementations, the request approval engine1331selects the computing resources from the connected network based on a type of task associated with the processing engine. For example, because the request approval engine1331performs tasks associated with presenting approver UI screens to approvers104and receiving request decisions from the approvers104, the request approval engine1331may determine that the selected network is the approver network1304.

In response to selecting the approver network1304for processing resource allocation, the request approval engine1331transmits an enhanced data packet1324to the approver network1304, which can also function as a command to the approver network1304to perform the request routing process1100or any other process associated with the request approval engine1331. For example, the enhanced data packet1324can include at least one of one or more request attribute vectors for the requesters for a particular request, the prioritization matrix for the request, or RQSs of the requesters. By condensing the information associated with the request and requesters into a single data structure that is transmitted as the enhanced data packet, vast amounts of data are condensed, which reduces computer network congestions. In addition, other processing tasks associated with other processing engines of the request management system108can be similarly distributed to the approver network1404as well as the requester network and external entity network. Once the computing resources of the approver network1304have performed the processing tasks associated with the enhanced data packet1324, the approver network1304transmits processing task results1330back to the request approval engine1331.

FIG. 14is an exemplary flowchart of a modification request process1400. The modification request process1400is controlled by the approved request management engine146, which automatically triggers other processing engines of the request management system108in real-time to perform one or more steps of the modification request process1400and processes the data received from the other processing engines in accordance with the steps of the process1400.

At step1402, the approved request management engine146receives a modification request submission from a requester who has received a decision approval. In addition to outputting request approval or disapproval information to the requesters102who submitted requests, the approved request management engine146also manages modification requests in response to receiving a modification request submission for an approved request from a requester102. In some implementations, the requesters102can submit a modification request associated with an approved request to modify one or more terms of the request. For example, the requesters102associated with the approved requests can also submit modification requests to modify a research funding term, increase or decrease a research funding award amount, modify sabbatical leave or retirement dates, etc. In some implementations, the approved request management engine146receives the modification request submission from the GUI engine150. The GUI engine150receives a modification request at a modification request interface screen where the requesters102can input a type of modification request as well as a reason for submitting the modification request.

At step1404, in response to receiving the modification request submission, the approved request management engine146determines whether the request is within predetermined decision terms that provide for automatic approval of the request. For example, the decision data154for a research funding request may indicate a maximum funding amount for a particular request. If the modification request is within the decision terms, resulting in a “yes” at step1404, then step1408is performed. Otherwise, if the modification request is not within the predetermined decision terms, resulting in a “no” at step1404, then step1406is performed.

At step1408, if the modification request is within the predetermined decision terms, then the approved request management engine146outputs an approval to the requester who submitted the modification request and at updates the decision data154in the data repository114to indicate that the approval was granted at step1410. For example, if the modification request is to increase a research funding amount to a total amount that is less than the maximum funding amount, then the approved request management engine146outputs a modification approval to the requester and updates the decision data154in the data repository114to indicate that the approval was granted.

At step1406, if the modification request is not within the predetermined decision terms, then the approved request management engine146triggers the request approval engine144to route the modification request submission through the approval chain to process the modification request submission. For example, the approval chain for the modification request submission is based on the type of modification request being submitted and can include one or more of faculty department heads, deans of colleges, dean of graduate studies, a head and members of a scientific council and various scientific council committees, university administrators, scientific council secretary, and secretary of the scientific council.

At step1412, once the approved request management engine146receives a final modification decision from the request approval engine144, the final modification decision is output to the requester who initiated the request, and the decision data154stored in the data repository114is updated.

FIG. 15is an exemplary screenshot of a modification request UI screen1500. The modification request UI screen1500may be output by the GUI engine150to requesters who have received approval decisions in one or more formats, such as email, notification on webpage or electronic device request, etc. The modification request UI screen1500includes multiple data fields and input fields that allow the requesters to input information related to modification request submissions. For example, the GUI engine150outputs a modification type input field1502that allows the requesters to indicate the type of modification request such as modify sabbatical leave length, modify retirement date, modify research funding amount, withdraw resignation, modify publication request, etc. The data input field1504allows the requester to input a personal statement explaining the reason for the modification request. At data field1506, the GUI engine150receives a submission selection where the requester can submit the modification request, check a status of a request, or cancel a request. The GUI engine150passes the modification request submission information input at the UI screen1500to the approved request management engine146for approval.

FIGS. 16A and 16Billustrate various aspects of an exemplary architecture implementing a platform1600for managing requests. The high-level architecture includes both hardware and software requests, as well as various data communications channels for communicating data between the various hardware and software components. The platform1600may be roughly divided into front-end components1602and back-end components1604. The front-end components1602are primarily disposed within a requester network1610including one or more requesters1612. The requesters1612may be located, by way of example rather than limitation, in separate geographic locations from each other, including different areas of the same city, different cities, different states, or even different countries. The front-end components1602may include a number of workstations1628. The workstations1628, for example, can be local computers located in the various locations1612throughout the network1610and executing various requests for ranking the approvers104with respect to preferences of the requesters102.

Referring now toFIG. 16A, the front-end components1602, in some embodiments, include a number of facility servers1626disposed at the number of locations1612instead of or in addition to, a number of workstations1628. Each of the locations1612may include one or more facility servers1626that may facilitate communications between the web-enabled devices1614and the back-end components1604via a digital network1630, described below, and between the terminals1628,1628A of the locations1612via the digital network1630, and may store information for a number of requesters/approvers/accounts/etc. associated with each facility. Of course, a local digital network1684may also operatively connect each of the workstations1628to the facility server1626. Unless otherwise indicated, any discussion of the workstations1628also refers to the facility servers1626, and vice versa. Moreover, environments other than the locations1612, such as the kiosks, call centers, and Internet interface terminals may employ the workstations1628, the web-enabled devices1614, and the servers1626. As used herein, the term “location” refers to any of these points of contact (e.g., call centers, kiosks, Internet interface terminals, etc.) in addition to the locations1612, etc. described above.

The front-end components1602communicate with the back-end components1604via the digital network1630. One or more of the front-end components1602may be excluded from communication with the back-end components1604by configuration or by limiting access due to security concerns. For example, the web enabled devices1614may be excluded from direct access to the back-end components1604. In some embodiments, the locations1612may communicate with the back-end components via the digital network1630. In other embodiments, the locations1612and web-enabled devices1614may communicate with the back-end components1604via the same digital network1630, but digital access rights, IP masking, and other network configurations may deny access of the web-enabled devices1614. The web-enabled devices may also connect to the network1630via the encrypted, wireless router1631.

The digital network1630may be a proprietary network, a secure public Internet, a virtual private network or some other type of network, such as dedicated access lines, plain ordinary telephone lines, satellite links, combinations of these, etc. Where the digital network1630includes the Internet, data communication may take place over the digital network1630via an Internet communication protocol. In addition to one or more web servers1690(described below), the back-end components1604may include a central processing system1640within a central processing facility. Of course, the locations1612may be communicatively connected to different back-end components1604having one or more functions or capabilities that are similar to the central processing system1640. The central processing system1640may include processing circuitry (e.g., one or more computer processors)1662adapted and configured to execute various software requests and components of the platform1600, in addition to other software requests, such as a medication management system.

The central processing system1640, in some embodiments, further includes a database1646(which may include one or more databases). The database1646can be adapted to store data related to the operation of the platform1600. The central processing system1640may access data stored in the database1646when executing various functions and tasks associated with the operation of the platform1600.

Although the platform1600is shown to include a central processing system1640in communication with three locations1612, and various web-enabled devices1614it should be understood that different numbers of processing systems, locations, and devices may be utilized. For example, the digital network1630(or other digital networks, not shown) may interconnect the platform1600to a number of included central processing systems1640, hundreds of locations1612, and thousands of web-enabled devices1614. According to the disclosed example, this configuration may provide several advantages, such as, for example, enabling near real-time uploads and downloads of information as well as periodic uploads and downloads of information. This provides for a primary backup of all the information generated in the wireless data transfer process. Alternatively, some of the locations1612may store data locally on the facility server1626and/or the workstations1628.

FIG. 16Aalso depicts one possible embodiment of the central processing system1640. The central processing system1640may have a controller1655operatively connected to the database1646via a link1656connected to an input/output (I/O) circuit1666. It should be noted that, while not shown, additional databases may be linked to the controller1655in a known manner.

The controller1655includes a program memory1660, the processing circuitry1662(may be called a microcontroller or a microprocessor), a random-access memory (RAM)1664, and the input/output (I/O) circuit1666, all of which are interconnected via an address/data bus1665. It should be appreciated that although only one microprocessor1662is shown, the controller1655may include multiple microprocessors1662. Similarly, the memory of the controller1655may include multiple RAMs1664and multiple program memories1660. Although the I/O circuit1666is shown as a single block, it should be appreciated that the I/O circuit1666may include a number of different types of I/O circuits. The RAM(s)1664and the program memories1660may be implemented as semiconductor memories, magnetically readable memories, and/or optically readable memories, for example. A link1635may operatively connect the controller1655to the digital network1630through the I/O circuit1666.

FIG. 16Bdepicts one possible embodiment of the front-end components1602located in one or more of the locations1612fromFIG. 16A. Although the following description addresses the design of the locations1612, it should be understood that the design of one or more of the locations1612may be different from the design of others of the locations1612. Also, each of the locations1612may have various different structures and methods of operation. It should also be understood that while the embodiment shown inFIG. 16Billustrates some of the components and data connections that may be present in a location1612, it does not illustrate all of the data connections that may be present in a location1612. For exemplary purposes, one design of a location is described below, but it should be understood that numerous other designs may be utilized.

Each of the locations1612, as illustrated, has one or more portable computing devices1633(e.g., notebook computers, tablet computers, smart phones, personal data assistants, etc.) and/or a facility server1626. The digital network1684and wireless router1631operatively connect the facility server1626to the number of portable computing devices1633and/or to other web-enabled devices1614and workstations1628. The digital network1630may be a wide area network (WAN), a local area network (LAN), or any other type of digital network readily known to those persons skilled in the art. The digital network1630may operatively connect the facility server1626, the portable computing devices1633, the workstations1628, and/or the other web-enabled devices1614to the central processing system1640.

Each portable computing device1633, workstation1628, requester device terminal1628a, or facility server1626includes a controller1670, as depicted inFIG. 16Bin relation to the server1626. Similar to the controller1655fromFIG. 16A, the controller1670includes a program memory1672, processing circuitry (e.g., one or more microcontrollers or microprocessors)1674, a random-access memory (RAM)1676, and an input/output (I/O) circuit1680, all of which are interconnected via an address/data bus1678. In some embodiments, the controller1670may also include, or otherwise be communicatively connected to, a database1682. The database1682(and/or the database1646ofFIG. 16A) includes data such as the types of data stored in the data repository114(FIG. 1) described previously. As discussed with reference to the controller1655, it should be appreciated that althoughFIG. 16Bdepicts only one microprocessor1674, the controller1670may include multiple microprocessors1674. Similarly, the memory of the controller1670may include multiple RAMs1676and multiple program memories1672. Although theFIG. 16Bdepicts the I/O circuit1680as a single block, the I/O circuit1680may include a number of different types of I/O circuits. The controller1670may implement the RAM(s)1676and the program memories1672as semiconductor memories, magnetically readable memories, and/or optically readable memories, for example.

Either or both of the program memories1660(FIG. 16A) and1672may also contain machine-readable instructions (i.e., software)1671, for execution within the processing circuitry1662(FIG. 16A) and1674, respectively. The software1671may perform the various tasks associated with operation of the location or locations, and may be a single module1671or a number of modules1671a,1671b. While the software1671is depicted inFIGS. 16A and 16Bas including two modules,1671aand1671b, the software1671may include any number of modules accomplishing tasks related to location operation.

In addition to the controller1670, the portable computing devices1633, the workstations1628and the other web-enabled devices1614may further include a display and a keyboard as well as a variety of other input/output devices (not shown) such as a scanner, printer, mouse, touch screen, track pad, track ball, isopoint, voice recognition system, digital camera, bar code scanner, RFID reader, etc. A requester102or approver104may sign on and occupy each portable computing device1633, workstation1628or requester device terminal1628ato assist the employee in performing his or her duties. Employees may sign onto the portable computing device1633, workstation1628or the requester device terminal1628ausing any available technique, such as entering a user name and password. If an employee signs on to the system using a portable computing device1633, the network1684communicates this information to the facility server1626, so that the controller1670may identify which employees are signed onto the platform1600and which portable computing device1633, workstation1628or requester device terminal1628athe employee is signed onto.

Various software requests resident in the front-end components1602and the back-end components1604implement functions related to location operation, and provide various user interface means to allow users (e.g., brokers) to access the platform1600. One or more of the front-end components1602and/or the back-end components1604may include a user-interface request1611for allowing a user to input and view data associated with the platform1600, and to interact with the platform described herein. In one embodiment, the user interface request1611is a web browser requester, and the facility server1626or the central processing system1640implements a server request1613for providing data to the user interface request1611. However, the user interface request1611may be any type of interface, including a proprietary interface, and may communicate with the facility server1626or the central processing system1640using any type of protocol including, but not limited to, file transfer protocol (FTP), telnet, hypertext-transfer protocol (HTTP), etc. Moreover, some embodiments may include the user interface request1611running on one of the web-enabled devices1614, while other embodiments may include the request1611running on the portable computing device1633in a location1612. The central processing system1640and/or the facility server1626may implement any known protocol compatible with the user-interface request1611running on the portable computing devices1633, the workstations1628and the web-enabled devices1614and adapted to the purpose of receiving and providing the necessary information during the data transfer process.

For purposes of implementing the platform1600, the user interacts with location systems (e.g., the central processing system1640) via a number of web pages.FIG. 16Cdepicts a web server1690connected via the network1630to a number of portable computing devices1633and other web-enabled devices through which a user1692may initiate and interact with the platform1600. The web enabled devices may include, by way of example, a smart-phone1694a, a web-enabled cell phone1694b, a tablet computer1633, a personal digital assistant (PDA)1694c, a laptop computer1694d, a desktop computer1694e, a portable media player (not shown), etc. Of course, any web-enabled device appropriately configured may interact with the platform1600. The web-enabled devices1633and1694need not necessarily communicate with the network1630via a wired connection. In some instances, the web enabled devices1633and1694may communicate with the network1630via wireless signals1696and, in some instances, may communicate with the network1630via an intervening wireless or wired device1631, which may be a wireless router, a wireless repeater, a base transceiver station of a mobile telephony provider, etc. Each of the web-enabled devices1633and1694may interact with the web server1690to receive web pages, such as the web page1698depicted inFIG. 16C, for display on a display associated with the web-enabled device1633and1694. It will be appreciated that although only one web server1690is depicted inFIG. 16C, multiple web servers1690may be provided for the purpose of distributing server load, serving different web pages, implementing different portions of the location web interface, etc.

Turning now toFIG. 16D, the web server1690, like the facility server1626, includes a controller1606. Similar to the controllers1655and1670, the controller1606includes a program memory1608, processing circuitry (e.g., one or more microcontrollers or microprocessors)1616, a random-access memory (RAM)1618, and an input/output (I/O) circuit1620, all of which are interconnected via an address/data bus1622. In some embodiments, the controller1606may also include, or otherwise be communicatively connected to, a database1624or other data storage mechanism (e.g., one or more hard disk drives, optical storage drives, solid state storage devices, etc.). The database1624may include data such as research institution web profiles, product data, web page templates and/or web pages, and other data necessary to interact with the user1692through the network1630. As discussed with reference to the controllers1655and1670, it should be appreciated that althoughFIG. 161depicts only one microprocessor1616, the controller1606may include multiple microprocessors1616. Similarly, the memory of the controller1606may include multiple RAMs1618and multiple program memories1608. Although theFIG. 16Ddepicts the I/O circuit1620as a single block, the I/O circuit1620may include a number of different types of I/O circuits. The controller1606may implement the RAM(s)1618and the program memories1608as semiconductor memories, magnetically readable memories, and/or optically readable memories, for example.

In addition to being connected through the network1630to the user devices1633and1694, as depicted inFIG. 16C,FIG. 16Dillustrates that the web server1690may also be connected through the network1630to the central processing system1640and/or one or more facility servers1626. As described below, connection to the central processing system1640and/or to the one or more facility servers1626facilitates the platform1600.

The program memory1608and/or the RAM1618may store various requests for execution by the processing circuitry1616. For example, a request1632may provide a user interface to the server, which user interface may, for example, allow a network administrator to configure, troubleshoot, or test various aspects of the server's operation, or otherwise to access information thereon. A server request1634operates to populate and transmit web pages to the web-enabled devices1694, receive information from the user1692transmitted back to the server1690, and forward appropriate data to the central processing system1640and the facility servers1626, as described below. Like the software1671, the server request1634may be a single module1634or a number of modules1634a,1634b. While the server request1634is depicted inFIG. 16Das including two modules,1634aand1634b, the server request1634may include any number of modules accomplishing tasks related to implantation of the web server1690. By way of example, the module1634amay populate and transmit the web pages and/or may receive and evaluate inputs from the user1692to facilitate in the wireless transfer of data from a first tablet to a second tablet, while the module1634bmay communicate with one or more of the back end components to provide the requested data.

Typically, a user may launch or instantiate a user interface request (e.g., a web browser or other requester request) from a web-enabled device, such as the web-enabled devices1633and1694, to access the web server1690cooperating with the system1640to implement the platform1600.

One or more processors can be utilized to implement any functions and/or algorithms described herein, unless explicitly stated otherwise. Additionally, any functions and/or algorithms described herein, unless explicitly stated otherwise, can be performed upon virtual processing circuitry (e.g., one or more virtual processors, for example on one or more physical computing systems such as a computer farm or a cloud drive).

Reference has been made to flowchart illustrations and block diagrams of methods, systems and computer program products according to implementations of this disclosure. Aspects thereof are implemented by computer program instructions. These computer program instructions may be provided to processing circuitry of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing circuitry of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The implementations described herein are directed to a request management system108that significantly improves the technology of systems and devices that manage decisions that are made for requests submitted by faculty members at a university. Being able to process requests in real-time, automatically determine a request quality score that provides an indication of whether the request should be approved, and manage the flow of requests through the approvers, the request management system108is fully automated and improves the efficiency of how the processing engines and data repositories interact with each other. The automatically triggering of the processing engines during execution of the processes of the request management system108increases the amount of processing that is done by the system108without any type of human interaction. Further, the ability to transmit the request attribute vector, prioritization matrix, and RQS for various requests to distributed computing resources improves the operational efficiency of the request management system108.

A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of this disclosure. For example, preferable results may be achieved if the steps of the disclosed techniques were performed in a different sequence, if components in the disclosed systems were combined in a different manner, or if the components were replaced or supplemented by other components. The functions, processes and algorithms described herein may be performed in hardware or software executed by hardware, including computer processing circuitry (e.g., processors and/or programmable circuits) configured to execute program code and/or computer instructions to execute the functions, processes and algorithms described herein. Additionally, some implementations may be performed on modules or hardware not identical to those described. Accordingly, other implementations are within the scope that may be claimed.