Patent Application
20230135058
The present invention relates to controlling a user interface of a computerized system to providing for asymmetrical, preferential allocation of limited or variable value clinical expertise.
There are many instances and contexts in which the level of expertise required, time sensitive nature of the need or value of the need varies, and/or demand exceeds available resources, and an allocation of limited resources must be made. Visibility into these needs and the value and shortages has been a consistent and growing problem, particularly in some cases, such as healthcare, in which the value and need is not knowable to those who have the required level of expertise. One such example involves scheduling of appointments for the right level or speed-of-delivery of services. For example, physicians, healthcare providers, medical testing labs and others in the medical/healthcare industry typically provide services to patients/persons according to scheduled appointments. Frequently, the demand for appointments exceeds the availability of appointments, at least on a short-term basis (e.g., over a matter of days, weeks, or months).
Often, resources in the nature of available appointments (days/times) are allocated on a non-differentiated, “symmetric” basis, without particular regard to prioritization or preferential scheduling for any appointments. For example, appointments with a dentist/hygienist for a routine dental cleaning/prophylaxis may be allocated to a requested patient on a next-available basis, in the order in which requests are made by patients. Sometimes, types of appointments may be prioritized. For example, an urgent need of one patient for a root canal or tooth repair due to extreme pain may be prioritized over a request for a routine dental cleaning by another patient. However, often, different patients requesting root canal/tooth repair may be scheduled symmetrically, such that all patients are provided with similar prioritization over more routine/less urgent types of appointments, but generally no prioritization is provided among all patients requiring the same service.
In some instances, it may be advantageous or desirable to provide for prioritization of appointment resource allocation among patients requiring the same service.
What is needed is a system and method providing a system and method for controlling a user interface to provide for asymmetrical, preferential scheduling of appointments on an incentivized basis.
The present invention provides a computerized system and method for controlling a user interface to provide for asymmetrical, preferential scheduling of appointments (allocation of limited appointment availability resources) on an incentivized basis. The system may be used, for example, by health plan operators to incentivize healthcare/medical providers to provide treatment to patients that are members of a particular health plan, to ensure treatment is rendered in better alignment with each individual patient's or plan's needs. Further, the system may be used by health plan operators to incentivize healthcare/medical providers to promote rendering of care in a manner providing better patient outcomes, or otherwise better meeting objectives of the health plan operator. Further still, the system may be used to provide financial or other reward to providers for better of faster care to patients. Other advantages including providing improved patient access to needed healthcare/medical resources, and the ability to align incentives with dynamic payment tools.
For a better understanding of the present invention, reference may be made to the accompanying drawings in which:
e illustrate exemplary graphical user interface windows displayable by the exemplary special-purpose Asymmetry-Based Scheduling System in accordance with an exemplary embodiment of the present invention.
The present invention provides a computerized system and method for controlling a user interface to provide for asymmetrical, preferential scheduling of appointments on an incentivized basis. Accordingly, prioritization may be provided among patients requiring the same service, such that some patients should receive preferential treatment/prioritization from service providers in scheduling appointments. For example, one patient may have a “deluxe” health care insurance plan providing a relatively high level of service and appointment prioritization, while another may have a “standard” health care insurance plan providing a relatively lower level of service, resulting in a lower prioritization in terms of scheduling an appointment with a provider. A health plan might want to prioritize the service/appointment request of one such patient over another patient having a different health plan, even assuming the same clinical need. Alternatively, a health plan member may have a higher clinical need, for instance due to a recent hospitalization, but appointment scheduling is done by the providers without the plan being able to influence the timing or payments at a higher rate. Any conventional prioritization is not provided on a per-plan, per-patient-basis and rather is left to other, haphazard scheduling, for instance by a discharge nurse or a family member. Accordingly, such an approach treats groups of patients similarly, regardless of their individual medical needs or the priority of the patients' health plan(s), and favors premium-based/plan-based preferential treatment, without focusing on the different medical/healthcare needs of individual patients.
Accordingly, the system may be used, for example, by health plan operators to incentivize healthcare/medical providers to provide treatment to patients that are members of the health plan, to ensure treatment is rendered in better alignment with each individual patient's or plans' needs. Further, the system may be used by health plan operators to incentivize healthcare/medical providers to promote rendering of care in a manner providing better patient outcomes, or otherwise better meeting objectives of the health plan operator. Further still, the system may be used to provide financial or other reward to providers for better of faster care to patients. Other advantages including providing improved patient access to needed healthcare/medical resources, and the ability to align incentives with dynamic payment tools.
According to illustrative embodiment(s) of the present invention, various views are illustrated in
The following detailed description of the invention contains many specifics for the purpose of illustration. Any one of ordinary skill in the art will appreciate that many variations and alterations to the following details are within scope of the invention. Accordingly, the following implementations of the invention are set forth without any loss of generality to, and without imposing limitations upon, the claimed invention.
An exemplary embodiment of the present invention is discussed below for illustrative purposes.
In accordance with a certain aspect of the present invention, one or more of the Provider Computing Devices 90a, 90b, and/or the Consumer Computing Devices 92a, 92b, 92c and/or Health Plan Operator Device 94 may store and execute an “app” or other purpose-specific application software in accordance with the present invention, although this is not required in all embodiments.
In accordance with the present invention, the network computing environment 100 further includes the Asymmetry-Based Scheduling System (ABSS) 200. In this exemplary embodiment, the ABSS 200 is operatively connected to the Provider Computing Devices 90a, 90b and the Consumer Computing Devices 92a, 92b, 92c and the Health Plan Operator Device 94 for data communication via the communications network 50. For example, the ABSS 200 may gather user data or other inputs from each device 90a, 90b, 92a, 92b, 92c, and 94 by data communication via the communications network 50. Hardware and software for enabling communication of data by such devices via such communications networks are well known in the art and beyond the scope of the present invention, and thus are not discussed in detail herein.
By way of example, the present invention may be used in the context of “three-way” scheduling (as opposed to traditional “two-way” approaches that only include two data points) for appointments for medical/healthcare services provided by medical/healthcare providers to patients/consumers. Accordingly, in the example of scheduling of appointments for medical/healthcare services, Provider Computer Devices 90a, 90b may be operated by medical/healthcare service providers, the Consumer Computing Devices 92a, 92b, 92c may be operated by patients or other consumers of medical/healthcare services, and the Health Plan Operator Device 94 may be operated by an operator of a health insurance plan.
After registration with ABSS 200, a Provider, Patient and/or Health Plan Operator may communicate with the ABSS 200 via the Provider, Consumer and/or Health Plan devices, and similarly, the ABSS 200 may communicate with the Providers, Patients Health Plan Operator via the Provider, Consumer and Health Plan Operator devices.
The Health Plan Operator (which can be a person or a computerized system operating programmatically) may use the Health Plan Operator Device 94 to define incentives to Providers for scheduling of appointments with one or more patients. In certain embodiments, the incentives may be defined for a class of patients, without reference to any particular patient, e.g., those having a particular condition, or having had a certain medical occurrence, etc. In other embodiments, incentives may be for a particular patient, on a per-patient basis. For example, the Health Plan Operator may define a financial incentive (e.g., an additional cash payment, an award of airline miles, a gift card, etc.) and/or a non-financial incentive, such as points towards recognition for seeing a particular patient for a particular purpose (e.g., for a behavioral health-type of appointment within the next 48 hours, to ensure that the patient's needs are met, or that a certain class of patients have follow-up or care or provider access according to the health plan's defined standards, preferences, etc.). By way of example, the Health Plan Operator may define these incentives by providing input to the ABSS 200 via a user interface provided at the Health Plan Operator Device 94 as a result of data transmitted from the ABSS 200 to the Health Plan Operator Device 94. Similarly, the ABSS 200 may transmit data to the Health Plan Operator Device 94 to cause display of alerts/messages describing the incentives, or alerting the Health Plan Operator to the existence/applicability of incentives.
In certain embodiments, a Provider may use the Provider Device to manage Provider resources, such as appointment capacity, by scheduling one or more patients for appointments with the Provider, to fill the provider's schedule as desired. In terms of assigning a particular appointment time to a particular patient, this may be performed and managed in a generally conventional fashion. By way of example, an appointment with a Provider may be requested by a patient by electronic communication, e.g., using the Consumer Computing Device, and a Provider may use the Provider Computing Device to assign an open appointment timeslot to a particular patient having made an appointment request. By way of example, the Provider may view incentives via the Provider Device 90a, 90b and schedule an appointment, perhaps as influenced by the available incentives, by providing input to the ABSS 200 via a user interface provided at the Provider Device 90a, 90b as a result of data transmitted from the ABSS 200 to the Provider Device 90a, 90b.
The scheduling information may be communicated from the Provider Device 90a, 90b to the Patient Computing Device 92a, 92b and/or to the ABSS 200, and may be managed by the ABSS 200 for the scheduling purposes described herein, namely, for permitting the Provider to interact with the ABSS 200 to schedule the appointment and to transmit data confirming the assigned appointment date/time, location, etc. to a Patient Computing Device and/or to effectively inform the ABSS 200 that the Provider is acting to earn the incentive. Alternatively, a message may go to all providers on the system to open new hours, such as evening or weekend hours, for a fee. Or the provider may have pre-set a threshold amount to automatically open certain hours automatically such that when the plan offers a cash or percentage-based bonus as an incentive to see a patient, the system may automatically add an open appointment and different potential times may have different thresholds. For instance, 5-6 PM might require a $20 or 20% increase in the fee but 6-7 PM may require $30 or 30%, in order for the system to automatedly add resource capacity (e.g., make an additional appointment available in those timeframes).
Accordingly, in accordance with the present invention, the definition of incentives and the communication of incentives to Providers, and the management of which patient to assign to an available appointment timeslot and/or which available appointment timeslot to assign to a requesting patient is performed in novel fashion, e.g., by way of the novel user interface of the ABSS 200 and/or the Provider Computing Device 90a, 90b, as described in greater detail below. More particularly, the Health Plan Operator may transmit data from the Health Plan Operator Device 94 to the ABSS 200 that will cause transmission of data from the ABSS 200 to the Provider Computing Devices 90a, 90b that cause display of financial and/or other incentives and/or associated notification messages to influence the Provider in scheduling an appointment with one or more patients to ensure that the individual patient receives appropriate care, or otherwise in accordance with the Health Plan Operator's objectives, as discussed in greater detail below.
Accordingly, the exemplary ABSS 200 of
The ABSS 200 may communicate with other computers or networks of computers, for example via a communications channel, network card or modem 220. The ABSS 200 may be associated with such other computers in a local area network (LAN) or a wide area network (WAN), and may operate as a server in a client/server arrangement with another computer, etc. Such configurations, as well as the appropriate communications hardware and software, are known in the art.
The ABSS 200 is specially-configured in accordance with the present invention. Accordingly, as shown in
Further, as will be noted from
As shown in
For example, the RM 240 may cause display of graphical user interface windows requiring a Provider to provide the following information as part of registration to create a user account for the provider: practice name, practice location/address, practice contact information, physicians, specialties, available procedures, insurances accepted, procedure pricing, availability for house calls. By way of example, this information may be gathered by the ABSS 200 by way of a graphical user interface window, such as windows 300, 400, 500 of
Similarly, the RM 240 may cause display of graphical user interface windows requiring a Consumer to provide the information as part of registration to create a user account for the consumer/patient, such as: name, location/address, contact information, preferred physicians, preferred specialties, preferred procedures, insurance, house call preference, e.g., during creation of a patient/consumer profile using the patient/consumer's smartphone, tablet, PC or other computing device to interact with the ABSS 200 via the network in an online data communications session. Notably, this user account information includes not only basic identity and contact information but also, in accordance with the present invention, includes additional information that may be useful in performing the incentivized scheduling functionality described herein.
Similarly, the RM 240 may cause display of graphical user interface windows requiring an Operator/Health Plan Operator to provide information as part of registration to create a user account for the Operator, such as: diagnosis, ability to use telehealth options, member ID number, etc.
In accordance with the present invention, the exemplary embodiment of the ABSS 200 shown in
After Provider registration, the IMM 250 is operable to cause display alerts, prompts, textual and visual notices, etc. as part of a Provider dashboard user interface window caused to be displayed to the Provider via the Provider Computing Device by the ABSS 200 (e.g., by the UIME 230). This process may be managed at least in part by the IMM 250. More particularly, in accordance with the present invention, the exemplary embodiment of the ABSS 200 shown in
In accordance with the present invention, the exemplary embodiment of the ABSS 200 shown in
The exemplary embodiment of the ABSS 200 shown in
System Operation
Exemplary operation of the system of
Further, the exemplary method may involve registering at least one patient with the ABSS 200. As discussed above, this may be performed at least in part by the RM 240 of the ABSS 200 causing display of graphical user interface windows at a Patient Computing Device 92a, 92b for gathering patient user account information. By way of example, this information may be gathered by the ABSS 200 by way of a graphical user interface windows, such as windows e.g., during creation of a physician/provider profile using the provider's smartphone, tablet, PC or other computing device to interact with the ABSS 200 via the network in an online data communications session.
Referring now to
The exemplary method next involves receiving Health Plan Operator input defining appointment scheduling incentives, as shown at 304. As discussed above, the incentive information may be stored in the data store 224 of the ABSS 200 as Incentive Data 224b, as shown at 306. This may be performed by the RM 240 and/or the IMM 250, and may involve communication among one or more of the Health Plan Operator Computing Device 94 and/or the ABSS 200.
Next, the exemplary method involves a Health Care Provider receiving a request for an appointment from a Patient, as shown at 308. By way of example, this may occur by a Patient inputting information into a suitable graphical user interface window caused to be displayed at the Patient Computing Device 92a, 92b by the Appointment Request Module 260 of the ABSS 200, or may occur by a Provider inputting information into a suitable graphical user interface window caused to be displayed at the Provider Computing Device 90a, 90b by the ARM 260 or the ABSS 200, e.g., when a patient places a telephone call to a Provider to request an appointment, or communicates with a Provider/Provider Computing Device 90a, 90b via a chat/text-based interface, which may be caused to be displayed by the Provider Display Module 290 of the ABSS 200.
In part, the PDM 290 may cause display of a graphical user interface window 950 showing graphically or otherwise appointment Availability Data 224e and Scheduled Appointment Data 224f, as well as causing updating of such data as changes by scheduling or canceling an appointment occurs. The graphical user interface window's alerts may be in the form of dynamic pop-ups, banners or other alerts displayed via the graphical user interface window, and the window may display a tall of cumulative incentives to date for a given period. As will be appreciated from
In this exemplary embodiment, the Provider Computing Device and/or ABSS 200 then checks for any incentives applicable to scheduling an appointment for the particular patient making a request, as shown at 310. For example, this may involve checking Provider Data 224c, Patient Data 224d, Operator Data 224a, Incentive Data 224b and/or Availability Data 224e.
In this exemplary embodiment, the ABSS 200 then references the stored data defining the appointment scheduling incentives, as shown at 312. By way of example, this may be performed by Scheduling Engine 270.
Referring again to the exemplary embodiment of
As will be appreciated from
The ABSS 200/PDM 290 may also display a graphical user interface window having a panel 1110 identifying surge offers/incentives for high-priority patients, and dynamic sorting of patients who have requested appointments, as will be appreciated from graphical user interface windows 1100, 1200 and 1300, shown in
It is then determined if the offered appointment is accepted, as shown at 318. If not, the method may end, as shown at 322. If so, then the offered appointment may be assigned to the requested patient, as shown at 320, and the method may end, as shown at 322. This assignment of the appointment may be performed by the Scheduling Engine 270, Patient Display Module 280 and/or Provider Display Module 290, and may involve communication among one or more of the Provider Computing Device 90a, 90b, Patient Computing Device 92a, 92b, and/or the ABSS 200. In accordance with the present invention, the ARM 260 and/or Patient Display Module 280 are responsible for managing requests that a patient be scheduled for an appointment with a healthcare provider, and thus for transmitting data via the network 50 to cause display of graphical user interface windows at one or more Patient Computing Device 92a, 92b for gathering information about appointments desired/requested. These requests may originate from the patients/Patient Computing Devices 92a, 92b, as will be appreciated from the graphical user interface windows 1400a, 1400b, 1400c, 1400d, 1400e of
If, however, it is determined at 314 that there are applicable incentives for scheduling of an appointment satisfying the request, then the ABSS 200 (in this embodiment) communicates to the Provider Computing Device 92a, 92b data identifying at least one incentive applicable to scheduling an appointment for the requesting patient, as shown at 324. For example, this may involve the ABSS 200 causing cause display of alerts, prompts, textual and/or visual notices, etc. as part of a Provider dashboard user interface window caused to be displayed to the Provider via the Provider Computing Device 92a, 92b by the ABSS 200 (e.g., by the UIME 230). This process may be performed at least in part by the IMM 250 and/or the PDM 290.
In this embodiment, the Provider Computing Device 92a, 92b then checks for appointment availability according to the patient's request, as shown at 326. For example, this may involve the Provider Computing Device 92a, 92b checking Availability Data 224e at the Provider Computing Device 92a, 92b and/or the ABSS 200. This may be performed by the Appointment Request Module 260, Patient Display Module 280 and/or Provider Display Module 290, and may involve communication among one or more of the Provider Computing Device 90a, 90b, Patient Computing Device 92a, 92b, and/or the ABSS 200.
Next, it is determined whether an appointment is available that is consistent with the incentive(s) available, as shown at 328. For example, this may involve identifying applicable Incentive Data 224b (e.g., applicable to a certain patient, health plan, health plan operator, healthcare provider, service, etc.) and comparing it to Availability Data 224e. For example, it may be identified that the patient request is of an appointment for a particular service, or with a particular provider, e.g., within a 2-week timeframe, and it may be identified that there is an incentive for the patient to be seen within 3 days, and it is determined whether there is a suitable appointment available within the next 3 days, consistent with the incentive. For example, this may involve the Provider Computing Device 92a, 92b checking Incentive Data 224b and Availability Data 224e at the Provider Computing Device 92a, 92b and/or the ABSS 200. This may be performed by the IMM 250, ARM 260, Scheduling Engine 270, Patient Display Module 280 and/or Provider Display Module 290, and may involve communication among one or more of the Provider Computing Device 90a, 90b, Patient Computing Device 92a, 92b, and/or the ABSS 200.
It is determined at 328 that there is an appointment available that is consistent with the incentive, then the system assigns the requesting patient an appointment on a prioritized basis consistent with the incentive, as shown at 330. For example, this may involve scheduling the patient for an appointment within the next 3 days, as discussed above, and the method may end, as shown at 322. This assignment of the appointment may be performed by the Scheduling Engine 270, Patient Display Module 280 and/or Provider Display Module 290, and may involve communication among one or more of the Provider Computing Device 90a, 90b, Patient Computing Device 92a, 92b, and/or the ABSS 200.
If, however, it is determined at 328 that there is no appointment available that is consistent with the incentive, then the system references stored Availability Data 224e to identify parameters for adding appointment capacity, as shown at 332. For example, the Availability Data 224e may indicate that a certain provider will make appointments available between the hours of 9 am and 4 pm on a regular basis, but will also see patients between the hours of 4 pm and 6 pm for a certain incentive (e.g., a minimum premium payment or other incentive having a value of at least $20) and will also make appointments available between the hours of 6 pm and 8 pm for a different incentive (e.g., a minimum premium payment or other incentive having a value of at least $50). For example, this may involve the Provider Computing Device 92a, 92b checking Availability Data 224e at the Provider Computing Device 92a, 92b and/or the ABSS 200. This may be performed by the Appointment Request Module 260, Patient Display Module 280 and/or Provider Display Module 290, and may involve communication among one or more of the Provider Computing Device 90a, 90b, Patient Computing Device 92a, 92b, and/or the ABSS 200.
Next, it is determined whether an available incentive matches/is compatible with/meets the parameters for adding appointment capacity, as shown at 334. For example, this may involve identifying applicable Incentive Data 224b and comparing it to parameters for adding appointment capacity of the Availability Data 224e. For example, it may be identified that there is an incentive to see the patient within the next 3 days that has a value of $30, and that that meets/matches with the parameter for adding additional appointment capacity between 4 pm and 6 pm of a minimum premium payment or other incentive having a value of at least $20. For example, this may involve the Provider Computing Device 92a, 92b checking Incentive Data 224b and Availability Data 224e at the Provider Computing Device 92a, 92b and/or the ABSS 200. This may be performed by the IMM 250, ARM 260, Scheduling Engine 270, Patient Display Module 280 and/or Provider Display Module 290, and may involve communication among one or more of the Provider Computing Device 90a, 90b, Patient Computing Device 92a, 92b, and/or the ABSS 200.
If it is determined at 334 that there is an available incentive that matches/is compatible with/meets the parameters for adding appointment capacity, then the system adds to the provider's schedule additional appointment capacity, e.g., an additional 4 pm appointment, consistent with the incentive, as shown at 336. This may be performed by the Scheduling Engine 270, Patient Display Module 280 and/or Provider Display Module 290, and may involve communication among one or more of the Provider Computing Device 90a, 90b, Patient Computing Device 92a, 92b, and/or the ABSS 200. The system then assigns the requesting patient the suitable appointment on a prioritized basis consistent with the incentive, as shown at 330, and the method ends, as shown at 322.
If, however, it is determined at 334 that there is no available incentive that matches/is compatible with/meets the parameters for adding appointment capacity, then the system offers the requesting patient/Patient Computing Device 92a, 92b an appointment (e.g., at a particular location, day, time, etc., with a particular provider, etc.) according to appointment availability without any incentive-based prioritization, as shown at 316, it is determined whether the offered appoint is accepted at 318, and the appointment is assigned to the patient if accepted as shown at 320, and/or the method ends, as shown at 322.
Accordingly, it will be appreciated that the present invention provides a computerized system and method for providing asymmetry-based scheduling of appointments, such that appointment requests are not handled only on a first-come first-served basis, but rather are handled on a prioritized basis, as that prioritization is reflected in incentives defined by the operator/health plan operator to promote scheduling of appointments in a manner consistent with the operator's objectives, e.g., to ensure better care to a group of patients in a need-based, prioritized manner. Further, Providers are provided with graphical user interfaces and system tools for scheduling appointments according to/starting with incentives offered, rather than simply in a manner that is responsive to an order of requests for appointments. Thus, the present invention provides a system that improves the efficiency of use of limited appointment resources, and has the ability to incentive and reward behavior desired by the operator, e.g., so that tasks valued more highly by the operator can be rewarded at a higher level of compensation.
The various implementations and examples shown above illustrate a method and system for performing asymmetric/prioritized resource allocation (e.g., appointment scheduling) using an electronic device. As is evident from the foregoing description, certain aspects of the present implementation are not limited by the particular details of the examples illustrated herein, and it is therefore contemplated that other modifications and applications, or equivalents thereof, will occur to those skilled in the art. It is accordingly intended that the claims shall cover all such modifications and applications that do not depart from the spirit and scope of the present implementation. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. By way of example, one or more system components or functions described with respect to any of the Provider Computing Device, Patient Computing Device, Health Plan Operator Device and the Asymmetry-Based Scheduling System may instead be incorporated in and/or provided by another one or more of such other devices and/or systems.
Certain systems, apparatus, applications or processes are described herein as including a number of modules. A module may be a unit of distinct functionality that may be presented in software, hardware, or combinations thereof. When the functionality of a module is performed in any part through software, the module includes a computer-readable medium. The modules may be regarded as being communicatively coupled. The inventive subject matter may be represented in a variety of different implementations of which there are many possible permutations.
The methods described herein do not have to be executed in the order described, or in any particular order. Moreover, various activities described with respect to the methods identified herein can be executed in serial or parallel fashion. In the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter may lie in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.
In an exemplary embodiment, the machine operates as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a server computer, a client computer, a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a smart phone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine or computing device. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
The example computer system and client computers include a processor (e.g., a central processing unit (CPU) a graphics processing unit (GPU) or both), a main memory and a static memory, which communicate with each other via a bus. The computer system may further include a video/graphical display unit (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system and client computing devices also include an alphanumeric input device (e.g., a keyboard or touchscreen), a cursor control device (e.g., a mouse or gestures on a touchscreen), a drive unit, a signal generation device (e.g., a speaker and microphone) and a network interface device.
The system may include a computer-readable medium on which is stored one or more sets of instructions (e.g., software) embodying any one or more of the methodologies or systems described herein. The software may also reside, completely or at least partially, within the main memory and/or within the processor during execution thereof by the computer system, the main memory and the processor also constituting computer-readable media. The software may further be transmitted or received over a network via the network interface device.
The term “computer-readable medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable medium” shall also be taken to include any medium that is capable of storing or encoding a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present implementation. The term “computer-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical media, and magnetic media.
The present invention may be operational with numerous other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the present invention include, by way of example only, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, cellular telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above-mentioned systems or devices, and the like.
The present invention has been described in the general context of computer-executable instructions, such as program modules or engines, being executed by a computer. Generally, program modules/engines include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. The present invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules/engines may be located in local and/or remote computer-storage media including, by way of example only, memory storage devices.
The exemplary computing system may include general-purpose computing hardware in the form of a server. Components of the server may include, without limitation, a processing unit, internal system memory, and a suitable system bus for coupling various system components, including a database cluster, with the server. The system bus may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus, using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.
The server typically includes therein, or has access to, a variety of computer-readable media, for instance, via a database cluster. Computer-readable media can be any available media that may be accessed by the server, and includes volatile and nonvolatile media, as well as removable and non-removable media. By way of example, and not limitation, computer-readable media may include computer-storage media and communication media. Computer-storage media may include, without limitation, volatile and nonvolatile media, as well as removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. In this regard, computer-storage media may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage device, or any other medium which can be used to store the desired information, and which may be accessed by the server. Communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information delivery media. The term “modulated data signal” refers to a signal that has one or more of its attributes set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above also may be included within the scope of computer-readable media.
The ABSS 200 may function as a server. The server may operate in a computer network using logical connections to one or more remote computers. Remote computers may be located at a variety of locations or over the Internet. The remote computers may be personal computers, servers, routers, network PCs, peer devices, other common network nodes, or the like, and may include some or all of the elements described above in relation to the server. The computing devices can be personal digital assistants or other like devices.
Exemplary computer networks may include, without limitation, local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. When utilized in a WAN networking environment, the server may include a modem/network card or other means for establishing communications over the WAN, such as the Internet. In a networked environment, program modules or portions thereof may be stored in the server, in the database cluster, or on any of the remote computers. For example, and not by way of limitation, various application programs may reside on the memory associated with any one or more of the remote computers. It will be appreciated by those of ordinary skill in the art that the network connections shown are exemplary and other means of establishing a communications link between the computers (e.g., the server and remote computers) may be utilized.
In operation, a user may enter commands and information into the server or convey the commands and information to the server via one or more of the remote computers through input devices, such as a keyboard, a pointing device (commonly referred to as a mouse), a trackball, or a touch pad. Other input devices may include, without limitation, microphones, satellite dishes, scanners, or the like. Commands and information may also be sent directly from a remote device to the server. In addition to a monitor, the server and/or remote computers may include other peripheral output devices, such as speakers and a printer.
Many other internal components of the server and the remote computers/computing devices are not shown because such components and their interconnection are well known. Accordingly, additional details concerning the internal construction of the server and the remote computers/computing devices are not further disclosed herein.
Although methods and systems of embodiments of the present invention may be implemented in a WINDOWS or LINUX operating system, operating in conjunction with an Internet-based delivery system, one of ordinary skill in the art will recognize that the described methods and systems can be implemented in any system supporting the functionality described herein. As contemplated by the language above, the methods and systems of embodiments of the present invention may also be implemented on a stand-alone desktop, personal computer, cellular phone, smart phone, tablet, PDA, or any other computing device used in various locations.
Additionally, computer readable media storing computer readable code for carrying out the method steps identified above is provided. The computer readable media stores code for carrying out subprocesses for carrying out the methods described herein.
A computer program product recorded on a computer readable medium for carrying out the method steps identified herein is provided. The computer program product comprises computer readable means for carrying out the methods described above.
While there have been described herein the principles of the invention, it is to be understood by those skilled in the art that this description is made only by way of example and not as a limitation to the scope of the invention. Accordingly, it is intended by the appended claims, to cover all modifications of the invention which fall within the true spirit and scope of the invention.
This application claims the benefit of priority of U.S. Provisional Patent Application No. 63/273,497, filed Oct. 29, 2021, the entire disclosure of which is hereby incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63273497 | Oct 2021 | US |
