Patent Application
20220076812
Various embodiments described herein relate generally to architecture, systems, and methods used to enable client interactions with providers of dental care and other services in-person and remotely.
Traditional approaches for providing dental care services may often provide patients with quality in-person care. However, the convenience and efficiency of service models may be in various ways unsatisfactory for all parties involved, including the services provider, the patient, and where applicable, third party payers (e.g. insurers). For example, patient options to interact with dental service providers are often cumbersome, time-consuming and expensive. In-office appointments may involve scheduling limitations, travel, in-office waiting and substantial expense, coupled for some patients with heightened concerns about potential exposure to infectious disease. Telephonic consultations may be difficult to schedule, with limited ability to communicate issues of concern, cost uncertainty and limited documentation of results. As a result of such issues, individuals often delay in seeking dental care, leading to greater pain and discomfort, as well as more costly and extensive remedial treatments later.
In other circumstances, patients may escalate service demands inappropriately, incurring high costs by seeking emergency treatment from a dentist or even hospital emergency room, when such treatment may not be necessary or could have been avoided by earlier intervention. Patients may have limited ability to identify an appropriate service provider for any given issue, leading to inefficient use of resources.
Meanwhile, information related to oral care and related services is often highly siloed and inefficiently utilized. Patients may have limited visibility into their insurance benefit coverage available for any given services. Patients often have little access to their own records; record requests may be slow, time consuming, and incur substantial costs (whether charged through to the requester or imposed as an administrative burden on the record holder). Patients may have little knowledge or understanding of dental products and services that may be relevant to them. In other situations, patients may be required to provide information multiple times to various service providers and insurers. Limited information availability to insurers may delay payments, cause erroneous coverage determinations, and impose significant burdens on care providers in submitting claims and responding to information requests.
These and other challenges may provide many opportunities for improvement.
In accordance with some of the aspects described herein, a patient—service provider communication or interaction platform provides integrated interactions across both remote consultation (e.g. teledentistry) and in-person service environments. A patient utilizes a patient electronic device, such as a mobile phone or other mobile communications device implementing software configured to implement functions described herein. The patient's location is evaluated to determine the patient's location relative to office locations associated with one or more dental service providers, such as using a Global Positioning System (“GPS”) integrated within a patient electronic device, geofencing, radiofrequency beacon, and/or QR code scanning.
A first set of functions are accessible to the patient when the patient's detected location is outside a service area associated with a dental service provider, including requesting a remote consultation with a dental service provider, and accessing information regarding prior service requests. When the patient is detected as being at a service provider location, a second set of functions is accessible to the patient, such as check in for an in-person dental service appointment, and querying the patient with health screening questions (responses to which are transmitted back to a network-connected server, for further communication to a service provider electronic device).
The patient electronic device may further detect a patient's proximity to an in-office kiosk, transmitting a unique identifier associated with the patient to the kiosk such that the kiosk initiates an in-person appointment check in procedure, which may include a health screening with infrared body temperature evaluation. The patient electronic device may also play back media content, such as patient education information or advertising, which may be selected based at least in part upon information accessible to the platform, such as information relating to a purpose for the patient's visit to a dental service provider.
Upon transitioning back away from the in-person service location, the patient electronic device may deliver reminders of follow up care tasks, or display information or advertising concerning products selected based at least in part upon relevance to the patient's current or prior consultation. Online purchase of advertised products may also be facilitated.
These and other aspects are described in detail below and in the accompanying drawings.
In accordance with some embodiments, a service provider-client interaction (SPCI) architecture (400, 420, 100C, 100D, 10) is provided that enables new and/or improved service provider and/or payee interactions with clients during many phases and types of services. In some embodiments, service providers such as dental care providers, medical care providers, and others may provide some or all of their services remotely, in-person, or via combination of remote and in-person interactions with one or more clients. To provide an example only, service providers that provide dental services, and clients (i.e. patients) seeking dental services, are described as one possible application of the SPCI architecture (400, 420, 10).
An exemplary environment in which such an embodiment may be implemented is illustrated in
A client 21A using CED 20A may be provided with immediate, on-demand access to a variety of personal and service records, via a SPCI mobile app or other computer application or webpage (a “SPCI-app”). For example, a client 21A may be able to review past activity and service history uploaded or memorialized by the SPCI architecture 400 (SPCI-history) by accessing selection 401A on the SPCI-app. A client 21A via their CED 20A may be to then view information such as: past chat dialog with a provider 31A-C; prior video consultations with a provider 31A-C (in some embodiments, including date/time/duration information, recordings of sessions, or computer-generated transcripts of sessions); and personal medical or dental records (such as x-rays or other medical/dental imaging, laboratory test results, prescriptions, and the like). In some embodiments, server 50 may query separate electronic medical records (EMR) systems in order to retrieve medical or dental records associated with a given user or patient. Such EMR may subsequently be, e.g., made accessible to a user via a history request 401A, made available to service providers in remote or in-person consultations, utilized as a factor for prioritization of remote service requests, and/or used for automated identification of predetermined conditions, whether conditions exhibited directly within the EMR or conditions determined by comparing EMR content to additional information provided by the patient (e.g. image-based identification of a missing tooth that is present in an EMR x-ray image).
For immediate or initial support, aid, or guidance, a client 21A may request a new remote service session (selection 401B). When a client 21A requests a new remote service session selection 401B, architecture 400 may enable a remote session between the client 21A and a service provider 31A-C (providers) via their respective electronic devices 30A-C. As described in more detail elsewhere herein, architecture 400 may direct or schedule a client 21A for a remote or in-person session with a provider 31A-E at locations 420A-C based on information available to the SPCI. Information that may be utilized by the SPCI for session scheduling and prioritization (i.e. “prioritization factors”) includes, inter alia: the client's 21A SPCI-history; one or more questions answered by the client 21A via the SPCI application or web interface (SPCI-app) on CED 20A (SPCI-questions); and information accessed from network-connected third party systems (e.g. patient brushing and other oral hygiene practices as monitored by a smart toothbrush cloud service), other devices (e.g. a Bluetooth-connected smart toothbrush), and/or other data stores or applications (e.g. importation of brushing or other information from other apps or system data stores within CED 20A). Based on such information, the SPCI may initiate a remote session (preferably with prioritization triaged based on information available to the SPCI), direct client 21A to in-person session (e.g. visiting an emergency room), or provide client 21A with patient education media or other media content (e.g. providing consultation or advice concerning the patient's condition using pre-recorded content items).
For immediate or initial service, a client 21A may request an in-person service session via selection 401C. In an embodiment, when a client 21A requests an in-person service session 401C, architecture 400 may first enable a remote session between the client 21A and a service provider 31A-C via their devices 20A-D, 30A-E to determine priority, scheduling (if any) and service provider selection for an in-person session. In an embodiment, architecture 400 may also directly schedule a client 21A for an in-person session with a provider 31A-E at locations 420A-C based on SPCI-history and SPCI-questions. Additionally or alternatively, architecture 400 may enable a fully remote session between the client 21A and a provider 31A-C via their respective devices 20A-D, 30A-E based on e.g. SPCI-history and SPCI-questions.
To determine or verify sessions (if any) that architecture 400 has scheduled for a client 21A, client 21A may select to view their service session schedule via CED 20A (selection 401D). Architecture 400 may show remote or in-person sessions scheduled for the client 21A. For example, for a remote session request, a client 21A may be in a queue to interact with a service provider 31A-E via their respective service provider electronic device (SPED) 30A-E. A client 21A may also be able to confirm, revise, or cancel a pending remote or in-person service session for a provider 31A-E in an embodiment. SPEDs 31 and CEDs 21 may be any of a variety of network-connected electronic devices facilitating digital communications with their users, such as a personal computer, smartphone or mobile phone, tablet computer, smart television, or voice interactive device such as Amazon Alexa. It is contemplated and understood that a given user may utilize multiple different CED, and a given service provider may utilized multiple SPED.
In accordance with some embodiments, the SPCI may be utilized to enable remote service provider consultations, such as tele-dentistry appointments or telehealth consultations, as a service delivery option within an integrated local-remote service platform.
When a client 21A via their device 20A requests a remote service session (401B), a SPCI-app on their device 20A may provide several options 403A-C, as illustrated in
Different service options may be provided to service providers, e.g. via provider devices 30A and 30B, including: review past remote services rendered by the provider 404A, 405A; view non-critical service requests 404B (e.g. requests in queue for the provider); view critical service requests 404C (e.g. requests in queue for the provider); review referral requests 405B, and view second opinion requests 405C.
In an embodiment, a client 21A may be able to request a non-critical remote service session (request 403B). In the context of an integrated dental services platform, request 403B may be utilized for patient issues such as requesting consultation on oral hygiene practices, learning about treatment options or available oral care products, or asking questions about non-acute conditions.
Upon receiving a request, SPCI server 50 may make a determination as to whether the requesting client should be presented with additional questions (i.e. requests for information) (step 915). The determination of step 915 may be made based upon, inter alia, information received by SPCI server 50 in request 403B. If so, SPCI server 50 may query CED 20A for additional information, with the requests for additional information presented to client 21A via the SPCI-app on their CED 20A (step 916). The SPCI server 50 may use an expert system 70B and/or voice analysis system 70A to form and present the additional questions, preferably customized or personalized based on e.g. the content of request 403B and/or related SPCI-history for the requesting user. For example, if a request in step 900 is categorized as a request for oral hygiene consultation and includes a photograph of a patient's teeth, in step 915 SPCI server 50 may evaluate the photograph to identify a broken tooth; and in step 916, client 21A may be further queried (e.g. via questions presented on CED 21A via SPCI-app) as to whether the patient's tooth has been newly broken in the preceding week.
In step 920, SPCI server 50 determines whether the non-critical request 403B should be escalated to a critical request queue. This determination may be made, in some embodiments, based upon information provided by client 21A in the original request (step 900) and/or in response to follow-up questions (step 916). In some embodiments, other sources of information may also be used, such as information accessed from network-connected third party systems (e.g. patient brushing and other oral hygiene practices as monitored by a smart toothbrush cloud service), other devices (e.g. a Bluetooth-connected smart toothbrush), and/or other data stores or applications (e.g. importation of brushing or other information from other apps or system data stores within CED 20A). If a determination is made to escalate, the client's request is moved to a critical service request queue (step 921). For example, in some embodiments, if a patient indicates that a tooth has been recently broken as a result of trauma, it may be desirable to escalate the patient's request to a critical queue. In some embodiments, the critical queue may be prioritized more highly for rapid handling, and/or assigned to different service providers (such as service providers having a higher level of expertise and/or training relevant to responding to critical issues).
While the embodiment of
In some embodiments, SPCI server 50 may also utilize information provided in connection with a request to determine whether the requesting client should be referred directly to an in-person service provider (step 925). This may be desirable, for example, where information presented in the original request or in response to follow-up questions suggests that the nature of the issue of such a nature that it cannot be effectively addressed by remote consultation, or is of a severity level that immediate in-person attention is required (such as by an urgent care or emergency facility 420B). If so, in step 926, SPCI server 50 transmits an in-person referral recommendation to client 21A via PED 20A (step 926). Such a referral may include, for example, a name and address of recommended service provider, contact information to schedule an appointment, and/or an automatically-scheduled appointment time.
As referenced elsewhere herein, machine learning techniques may be beneficially utilized in connection with a variety of aspects of the SPCI. For example, machine learning techniques may be utilized to optimize the automated determination of suitability of a request for remote consultation for a remote session, as opposed to an in-person service consultation. Such a machine learning component may be implemented internally by server 50, externally (e.g. via a RESTful API integrating to a third party and/or separately hosted machine learning pipeline), or otherwise. In the event that a remote consultation is initiated, server 50 may solicit feedback as to whether the patient's need was well-suited for remote consultation, and that feedback may be utilized as ongoing training input to the machine learning component. Similarly, a machine learning component (whether implemented by server 50, externally, or combinations thereof) may be utilized as a priority classifier to prioritize patients' requests for remote service consultations in queue; and feedback may be requested from service providers having conducted a remote consultation as to the priority level the service provider would have assigned to the consultation request, which response may be utilized as training feedback for the machine learning priority classifier.
Various criteria may also be considered in assigning remote service requests to a subset of potential service providers, including: a specialization with which the remote service provider is associated, as compared the details of the service request; the availability of remote service providers (whether scheduled or reported by the service provider in real time), and records of prior interactions between a patient and service provider (e.g. prioritizing service providers having previously treated the patient or for whom a prior interaction was rated highly). In some embodiments, machine learning components or expert system components may also be utilized to assist in matching of service requests with service providers; inputs may include information from the patient concerning the consultation request, information from the patient profile or past services; provider specializations; and other information. Service providers may provide feedback as to the appropriateness of the patient match, and such feedback may be utilized as training input for the matching algorithm.
If the request is maintained in a queue for remote service, client 21A may then await connection with a provider for communication between CED 20A and a provider electronic device (step 930).
In some embodiments, clients awaiting providers may be presented with content via their SPCI-app while waiting. Content delivered while waiting on queue may include, for example, advertising or patient education information. Furthermore, content delivered on queue may be highly targeted or personalized, based on detailed information concerning client 21A maintained by or accessible to SPCI server 50. While examples are described herein with reference to a remote dental services application, it is contemplated and understood that the systems and methods described may be equally applicable to telehealth consultations or other remote services.
For example, information received by SPCI server 50 in connection with a service request (e.g. in step 900) and/or in response to further query (e.g. in step 916) and/or associated with the requesting client in a user profile maintained by SPCI server 50, may be utilized to target or personalize content delivery. In some embodiments, content may be selected for playback to a given user while waiting in queue, that is deemed likely to be of interest to the user, whether the delivered content comprises advertising, patient education materials or other content. For example, in some embodiments, if a user initiates a non-critical service request for consultation on oral hygiene and the user's historical service information indicates recent orthodontal work, during step 930 the user may be presented with (a) advertising for orthodontal appliance cleaning products; and/or (b) instructional videos on cleaning of orthodontal appliances.
In some embodiments, content sponsorship may also be utilized (exclusively or as one factor in a recommendation or personalization algorithm) in selecting content for delivery to user 21A while waiting on queue. For example, toothpaste manufacturers may bid for advertising delivery to targeted user cohorts (e.g. users seeking consultation about dental hygiene practices). Because SPCI server 50 has access to a particularly rich and varied ecosystem of information relevant to not only a user 21A, but also the user's contemporaneous interests (e.g. as expressed via current and/or historical requests for service or other prior transactions), SPCI server 50 may be particularly effective in selecting and delivering content that is timely and relevant to user 21A.
In addition to transmitting content such as patient educational content and/or targeted advertising while a patient is in queue for a remote consultation, the SPCI platform may also deliver targeted content (whether patient educational, advertising, or both) via a user 21A's mobile app, when the patient's device 20A is determined to be located within a dental service provider's offices. Thus, content relevant to a patient's current condition can be delivered to the patient while waiting to visit with a dental professional, thereby engaging the patient and potentially reducing patient dissatisfaction associated with any waiting period.
In an embodiment, a client 21A may be also able to request a critical remote service session (request 403C). In the context of an integrated dental services platform, request 403C may be utilized for patient issues such as acute pain, a newly broken tooth, broken orthodonture, or the like.
As with the non-critical queue workflow, upon receiving a request, SPCI server 50 may make a determination as to whether the requesting client should be presented with additional questions (step 1015), and if so, additional questions may be presented to user in step 1016 (similarly to step 916). Optionally, a determination may be made as to whether critical queue requests should be de-escalated to the non-critical queue (i.e. the inverse of steps 920 and 921), although it may be desirable not to do so to avoid erroneously de-escalating a genuinely critical patient request.
As with the non-critical request workflow of
In services areas such as dental, payer responsibility may be complex and may vary by service or product. For example, some types of services may be partly or wholly paid by an insurer or a self-insured employer. Some services may entail full or partial payment by a patient, either directly or via a Health Savings Account or Flex Spending Account. Some services may be paid for via a subscription service. Similarly, oral care products may be payable by, inter alia, some combination of an insurer, employer, patient out-of-pocket, patient HSA or patient FSA. Thus, in some embodiments, it may be highly desirable to implement automated payment and billing functionality, as described herein throughout, thus potentially providing additional clarity to patients, and potentially improved collection time and reduced administrative burden for providers and payers.
In some embodiments, the SPCI may facilitate online direct payment by a client 21A, e.g. via the SPCI-app on their device 20A, to pay for a requested or completed remote service session or other product or service. The SPCI-app may enable a client 21A to pay via a 3rd party (such as insurance company) when applicable or other electronic payments such as Paypal®, credit card, EFT, bank checking account, Venmo®. The SPCI server 50 may communicate insurance information required and received from a SPCI-app on a device 20A to a 3rd party payor system 80B for processing, confirmation, and payment. The SPCI server 50 may also communicate electronic payment information received from a SPCI-app on a device 20A to a payment system 80A for processing, confirmation, and payment. The SPCI server 50 may forward payment from system 80A or 80B to a service provider 31A, B based on their election as applicable in an embodiment.
In some embodiments, the SPCI server 50 and/or device 20A implementing an SPCI-app, may enable presentation of informational content to a user 21A, such as educational information about various services relating to a client's service request. Such content may be presented automatically by SPCI server 50, automatically by operating of device 20A implementing SPCI-app, at the request of a service provider 31A, 30B, and/or upon request of a client 21A (e.g. via searching for content using device 20A and the SPCI-app, in some circumstances interacting with search module 88A within server 50). Information received by SPCI server 50 relating to a user's service needs or condition (e.g. information received in steps 900, 916, 1000 or 1016, information stored in distributed ledger 40A, and/or information stored within a database implemented by server 50A) may be utilized to personalize and/or prioritize selection of client education content for presentation to client 21A.
The content to be presented to client 21A may include, inter alia, articles, multimedia such as videos, webpages, audio and other data. The content may have subject matter relating to a current service request from client 21A, a past service request from client 21A, information deemed relevant based on profile or biographical information associated with client 21A, or other subject matter. Video may be provided via a third party online video hosting source such as YouTube®, Facebook®, Vimeo, and others. Other content may likewise be hosted externally.
In some embodiments, the SPCI server 50 may receive service-related educational information from an education system 70C, which may be hosted by another service provider. The education information may include information about the requested service(s) and related services in an embodiment.
In some embodiments, client education information may be presented via a SPCI-app while a patient is waiting in queue for a remote service session. In some embodiments, client education information may be presented via in-app content, made available for a web portal, and/or transmitted to a user via messaging (such as email, SMS, or in-app notifications from the SPCI-app).
In an embodiment, the SPCI server 50 automatically or at the request of a service provider 31A, 31B may enable a client 21A via their SPCI-app (on their device 20A) to purchase products or services related to their service request. For example, for a dental service, the related products may be dental products to prevent future service (e.g. toothpaste, fluoride rinse, a power toothbrush, a brushing coaching aid, or the like) or to help address any current dental issues (e.g. pain relievers, whitening products, or the like). In an embodiment, the SPCI server 50 may provide related products or services information or links for their purchase from a 3rd party sales system 70D, which may be hosted by another service provider. The SPCI server 50 may also enable the SPCI-app of a device 20A to communicate directly with a 3rd party sales system 70D to purchase related products or services.
In addition to enabling remote consultation sessions and/or remote access to information, the SPCI platform may also provide functionality when a user is physically present at a service provider's location. Thus, the SPCI platform and SPCI-app may provide a wholly-integrated platform for monitoring, managing and participating in all aspects of a user's services, whether remote or in-person.
In particular, SPCI architecture 400 may be employed at a service providers 31A-E location 420 during the in-person service session for one or more clients. As shown in
In some embodiments, a service-provide SPCI-app may be utilized for various aspects of patient check in within an in-person service environment, including a patient health screening. Reception area room 430A may include a service provider device 320A located therein. Device 320A may be a computing device kiosk, such as a floor-standing kiosk or a wall-mounted kiosk. Patients entering room 430A may be directed to check in using kiosk device 320A.
A service provider SPCI-app of a device 320A may automatically detect when a person-client is near the device 320A (activity 502 of algorithm 500 of
In some embodiments, service provider device 320A may be utilized to implement a health screening, before checking a patient in for an in-person service appointment. For example, device 320A may include an infrared scanner configured to perform an infrared scan of a client standing before device 320A to determine their current temperature based on measurement of infrared radiation, and confirm that the person's temperature is within acceptable limits or direct the client-person to an emergency, urgent care, or similar facility 420A if their temperature is elevated beyond current acceptable limits (such as during an outbreak in the community) (activities 506, 508). The health screening performed by device 320A may additionally include querying the user with questions concerning their health condition, such as presence of body aches, cough, other current condition, or recent exposure to potentially infectious individuals.
The service provider SPCI-app of a device 320A, may employ neural logic, AI, or machine learning (whether implemented locally or via call to remote computation resources) to analyze the infrared image of the client to determine their temperature (such as via
Then a service provider SPCI-app of a device 320A may automatically detect the client identity based on their voice or image(s) stored in a database (activity 512) and may use neural logic, AI, or machine learning to do so, employ the SPCI server 50, or expert system 70B as described in relation to determining their temperature.
In some embodiments, the client's identity and proximity to device 320A may be determined via short range radiofrequency communication with a mobile user device 20A. For example, device 320A and user device 20A may exchange data using Bluetooth communications. Alternatively, provider device 320A may include a wireless beacon, detectable by a SPCI-app mobile application operating on user device 20A, causing device 20A to report its proximity to device 320A via, e.g., a network communication therebetween.
If the client identity is detected, a custom welcome page for the client may be provided on the device 320A (activity 516) via the SPCI-app. Otherwise, the client may be requested to register with the system 320A and download the SPCI-app on their personal device 20A-D. Their image and voice data may be stored in a database based on their registration (activity 514).
Then the client may be able to check in for a service session (activity 518, 524), and/or select an available appointment (walk-in, activity 522). Then if there is time before their schedule session (activity 526), the device 320A via SPCI-app may provide related session product sales and related session education (activity 528). Once the client has left the area of the device 320A, which its camera 322A-C may detect (activity 532), the device 320A may reset the screen to a preset display (such as shown in
Another client 21B may check in via their personal device 20A. In an embodiment, an SPCI-app on their device 20A may be location aware and provide different functionality (such as check in, health screening (temperature check for example), related session product sales, and related session education) when determined to be near a service provider location 420. Further, a service provider 31A may perform similar activities for an incoming or departing client 21A-D via an SPCI-app on their device 30A.
A client 21C in a room 430B awaiting or completing a service session via their device 20B or an interactive television and keyboard 331B may similarly be able to review session options and education about the options, SPCI-history, payment options, and session related products (for sale). A service provider 31E in a room 430D via a portable computer 30E (tablet or the like), interactive television 330C, or the client's device 20D may also be able to present session options and education about the options, SPCI-history, payment options, and session related products (for sale) to the client 20D via SPCI-app running on devices 20B, 20D, 330B-C. Service providers 31B, 31C via an SPCI-app on their devices 30B-C may be able to review session status for clients, completed consents, payment status, update other provider's 31A, D, E schedules and direct or control the SPCI-apps or information being provided or shown on various devices 320A, 330A-C, 30A-E in the location 420. Similarly, service provider 31D via their device 30D may be able to review session status for clients, completed consents, payment status, update other provider's 31A-C, E schedules and direct or control the SPCI-apps or information being provided or shown on various devices 320A, 330A-C, 30A-E in the location 420. Service provider 31D in room 430E may also be able to control the display on device 330A to show options, SPCI-history, payment options, and session related products (for sale) to a client 20A-D when in their room in an embodiment.
A variety of mechanisms may be provided for interaction between clients and service provider device 320A. In some embodiments, device 320A will include a large touch-screen and/or keyboard for touch-based interactions. In some embodiments, device 320A will include a speaker to convey audible instructions, and a microphone coupled with voice recognition and natural language processing capabilities, to enable voice interactions without requiring an individual to actually touch kiosk 320A. In some embodiments, service provider device 320A may communicate wirelessly with a user device 20 so that a client may type, tap or swipe user device 20 (e.g. via a SPCI-app implemented thereon) to transmit communications to provider device 320A, thereby minimizing the role of provider device 320A as a shared contact point and potential source for transmission of infectious agents.
Aspects of the in-person service platform are described herein with respect to a user device, client device or patient device (e.g. devices 20A, 20B). In some embodiments, such personal electronic devices may be owned by the patient and brought by them into the service environment. Use of the patient's own device may be desirable for, e.g., minimizing needs for patients to touch common surfaces and thereby reduce risk of spread of infectious disease. However, in other embodiments, the devices (e.g. devices 20A, 20B) may be provided to a patient, by a service provider, for temporary use during the in-person visit. For example, an in-chair tablet may be provided, implementing the SPCI-app, in order to facilitate viewing of content such as patient education materials, treatment plans, completing check in procedures, signing consents and approvals, viewing of advertisements or promotional materials for relevant products and services, and the like.
As noted above, a client device 20A, 20B SPCI-app may provide different options as function of its detected location or user-client selection. Client location within a service environment may be determined in a number of ways, such as using wireless beacon technology, location services, manual selection, QR code scanning by a client device 20A of QR codes located throughout a service provider's environment, or the like.
For example, client device 20A when located in the check-in area or room 430A SPCI-app may provide a check-in, service review, and health check options (as shown in
For a client's device 20B at a different location (such as in room 430B waiting to receive services), a SPCI-app may provide information-education about services and related services, options to purchase related products or services, in addition to the ability to authorize or consent to various services or options. In an embodiment, the SPCI-app for a client device may be programmed to provide different options-functions based on the specific location of the device 20A-B within a service provider environment 420. In an embodiment, a service provider 31A-E via an SPCI-app on their device 30A-30E may be able to control the options a client's device 20A-B presents at different locations in their environment 420.
Similarly, a service provider 31A-E via an SPCI-app on their device 30A-30E may be able to control the options presented on their service devices 320A, 330A-330C at different locations in their environment 420 as shown in
As briefly mentioned hereinabove, service provider device 320A in the waiting or check in room 430A of environment 420 may be an interactive television or custom configuration kiosk as shown in
As shown in
As shown in
In an embodiment, when a client's device 20A-D is not near a service provider 31A-E location, the SPCI-app may provide remote service options including the ability to view their SPCI-history (activity 552 and 554), selecting a remote service session (activity 556), request an in-person service session (activity 558), and view their current service schedule (for already request in-person or remote services) (activities 562, 564). When a client 21A via the SPCI-app requests a remote service session, they may be able to request a non-critical service session (activities 566, 568), a critical service session (activities 572, 574), and other service activities (activities 576, 578).
As described above, a SPCI-app on a client device 20A-D, service provider device 30A-E, 320A, 330A-C, SPCI server 50, or an external expert system 70B may use neural logic, artificial intelligence, or machine learning to determine the identity or temperature of a client 21A-D. The same neural logic, artificial intelligence, or machine learning may be used for automated identification of other states or conditions of a client 21A-D or an item they want serviced (for example view images of clients' teeth and compare to stored x-rays to detect an anatomical change requiring service, view images of tires of a client's vehicle and determine the type, size, and condition (under-over inflated, tread depth too low, damaged side wall, un-natural shape) of tires that may need replacement or service). For example, such analysis may be performed prior to contacting a service provider 31A-E via their SPCI-app on their device 30A-E to conduct a remote interactive session between a service provider and a client so their interaction may be more effective and efficient for both parties.
Accordingly, an embodiment may use neural logic, artificial intelligence, or machine learning to provide triage or concierge services or analysis before, during, after remote or in-person services. For example, an embodiment of a SPCI-app on a client device 20A-D, service provider device 30A-E, 320A, 330A-C, or SPCI server 50 may employ a neural network architecture 600A-D as shown in
As shown in
In a further embodiment, a neural network architecture 600C shown in
Different sets of neural networks 600A-600D may be trained/formed and updated (evolve) for a particular activity of a service analysis-procedure. One or more L/M/P may be developed based on availability of image data to perform a particular activity of a session procedure. The different sets of neural networks 600A-600D may be trained/formed and updated (evolve) for a particular activity of a session analysis-procedure based on the developed one or more L/M/P.
In an embodiment, all client data including images and any analysis, past service interactions, tests, communications, and service(s) provided (SPCI-history) may be stored by the SPCI server 50 or off-site system 40A. Such storage may enable a SPCI-app to retrieve past service interactions, tests, analysis, communications, and completed service(s) to enable a service provider 31A-E to be able to provide enhanced or more beneficial future service(s) for a client 21A-D. In addition, a client 21A-D may have access to their entire SPCI-history via an SPCI-app on their device 20A-D.
As noted, a service provider 31A-E may be a medical provider and the client 21A-D may be a patient in SPCI architecture 10, 400, 420, 100C, 100D.
In an embodiment, the CBCS 40A-40B may include certificate authority entities that create or issue digital certificates. In an embodiment, the CBCS 40A-40B may employ cryptographically linked blocks in an open, distributed ledger termed blockchains and hereinafter systems 40A-40B are referred to as CBCS although they could be any cryptographic provider, system, software, or entity and provide cloud services.
In an embodiment, a client device 20A-D, a provider device 30A-30E, a CBCS 40A-40B, an admin system 60A-60B, other provider system 70A-70D, and payment systems 80A-80B may communicate with a SPCI server 50A-50B via one or more networks 16 where the networks may be local wired or wireless networks or a network of networks such as the Internet.
In an embodiment, a client via a client device 20A-D (hereinafter 20A for simplicity) via a local SPCI application, real-time SPCI application, or web-based SPCI interface (such as browser) (herein after client SPCI-app) may interact with a SPCI server 50A (such as via main user interface 25C in
As noted above, a SPCI server 50A may communicate with a payment system 80A (such as Stripe®, Venmo®, credit card processor, bitcoin, Paypal®, EFT processor, or others) to process payment to a provider device 30A for services provided (such as provided services show on pages 35M-N in
In an embodiment, a SPCI server 50A may communicate with a CBCS 40A to store client and provider information and activity including payment, login, security, requested services, provided services, communications, and other information in a blockchain via a block chain system module 86A (shown in
In an embodiment, the CBCS 40A-40B (hereinafter 40A for simplicity) may employ cryptographically linked blocks in an open, distributed ledger termed blockchains in addition to digital certificates from cryptography certificate authority entities. A CBCS system 40A employing blockchains (hereinafter CBCS 40A for simplicity) may generate digital certificates, identifiers (IDs), or tokens than are unique and tied and copied/distributed to a plurality of systems 40A to secure the digital certificates, identifiers (IDs), tokens, client information, provider information, services requested and performed and related communications, and payments. Similarly, in an embodiment any updates associated with SPCI architecture 10, 100C, 100D, 420, 400 such as the client information, provider information, services requested and performed and related communications, and payments, may be distributed across many blockchain systems 40A to prevent corruption of SPCI architecture 10, 100C, 100D, 420, 400 data and provide a secure and reproducible record or ledger of all activity along with the source of such changes. In an embodiment, all client information, provider information, services requested and performed and related communications, and payments may be assigned a unique token that is created and stored by a CBCS 40A
In an embodiment as shown in
In an embodiment, a provider device 30A, client device 20A, and admin system 60A may host a local SPCI application, real-time SPCI application, or web-based SPCI interface (such as browser) (herein after admin SPCI-app) 28 and 38, each of which may maintain a local store of data 29A and 39A, respectively. The web-based SPCI interface may include a web browser such as Internet Explorer, Edge, Safari, Netscape, Chrome, Firefox, or Opera, VR system, or AR system where the SPCI-app may communicate with the SPCI server 50.
In an embodiment, a provider device 30A, client device 20A, admin system 60A, CBCS 40A, and other providers system 70A via their interfaces 32A, 22A, 62A, 42A, and 72A may be any computer device capable of hosting an interface that can communicate with a SPCI server 50A including via web browser application 28, 38 runtime application, VR system, AR system, application programming interface (API), or other application as noted. A provider device 30A, client device 20A, admin system 60A, CBCS 40A, and other providers system 70A may include a processor with a network interface 32A, 22A, 62A, 42A, and 72A including a server, virtual server or system, personal computer, personal data assistant, interactive television, cellular phone, video game console, or tablet computer.
In an embodiment, a SPCI server 50A may employ a web framework (WF) or web application framework (WAF) including Ruby on Rails, Java, Python, Apache, Django, or other software or architecture to provide web pages, framework, or wire frames to a provider device 30A, a client device 20A, and an admin system 60A. A SPCI server 50A may also employ Software as a Service (SaaS) to provide data and executable instructions (an SPCI-app) to a provider device 30A, a client device 20A, and admin system 60A. In an embodiment, webpages may be built using on a Rudy on Rails framework or other web frameworks. In an embodiment, a provider device 30A, a client device 20A, and an admin system 60A may host an SPCI-app operating natively where the application communicates data with the SPCI server 50A (such as a SPCI application downloaded from an application provider or provided by the SPCI server 50A).
A provider device 30A, a client device 20A, and an admin system 60A may use various operating systems including Microsoft operating systems (Windows), Linux, Mac OS X, Android, WEB OS, and others to run a SPCI-app. In an embodiment, a SPCI server 50A may provide SPCI-app to run natively on a client device 20A. Such an interface may enable VR system, or AR systems to operate on a client device 20A.
In architecture 10, a client 21A or a provider 31A may be required to register with/login to a SPCI server 50A via a SPCI-app on their device 20A, 30B—communications 102A-B, 112A-B of
This unique ID for a client 21A or a provider 31A may allow them to create a secure history (SPCI-history) in the architecture 10, 100C, 100D, 420, 400 so another client 21B-D or another provider 31B-E may view their SPCI-history (as permitted) as they use architecture 10, 100C, 100D, 420, 400 over time. In an embodiment, the unique ID or IDs for a client 21A or a provider 31A may include one or more blockchain tokens that are uniquely and securely associated only with the client 21A and the provider 31A. The SPCI server 50A may receive and store the generated unique ID(s) or token(s) for the client 21A and the provider 31A.
Once registered, a client 21A or a provider 31A may login into a SPCI server 50A via a client SPCI-app or provider SPCI-app on their devices 20A, 30A, thereafter using secured protocols. In an embodiment, a client 21A or a provider 31A may be able to create a profile and add images (36D in
Once registered or logged into a SPCI server 50A, a SPCI server 50A may generate and provide/forward a main page 25A, 35A (communications 106A-B, 115A-B) to a SPCI-app on a client device 20A, a SPCI-app on a provider device 30A via a network 16, such as the graphical user interface screens 25A, 35A shown in architecture 10 in
As shown in
In an embodiment, the service-related data may include unique ID(s) created for the provider completed service requests and related information and client posted service requests and related information. The application interfaces and blockchain system interfaces/protocols 54 may include data associated with interfacing with the CBCS 40A and devices 20A-D, 30A-E, 40A, 60A, 70A-D, 80A-B, 320A, and 330A-C in an embodiment. As shown in
As shown in
In an embodiment, a service provider 31A may be any individual or group that may provide services for a client 21A including a dentist or any staff member providing services to a patient in an embodiment. As noted, via page 35A and 35D, a provider 31A via SPCI-app on their device 30A may select a pending service request from a queue of service requests (from clients) (34A, 44D) (activity 152A of
As shown in
In an embodiment, a service provider 31A via SPCI-app on their device 30A may be able to forward a received service request 44D to another provider 30B_E (via SPCI-app on another device 30B-E or other system) for a second opinion on the processing of the service request. In addition, a service provider 31A via SPCI-app on their device 30A may be able to forward a received service request 44D to their staff or related service provider (such as another professional, assistant, manager) (via SPCI-app on another device 30B-E or other system) for at least partial processing of the service request.
When a service provider 31A selects to provide new service via SPCI-app on their device 30A, interface 35N shown in
In an embodiment, a service provider 31A via SPCI-app on their device 30A may be able to provide initial steps required to complete a service request. The service provider 31A via SPCI-app on their device 30A or SPCI server 50 may refer a client 21A via SPCI-app on their client device 20A to an in-person meeting with the service provider 31A or another service provider 31A to conduct additional steps of the service request. The service provider 31A due to regulations or other factors may not be able to request or order procedures required to complete a service request for a client 21A, e.g., a dentist may be required to see a patient in person in order to request x-rays or other tests that may be required to treat (provide service) to the client 21A. In an embodiment only initial service may be completed and noted by 39N.
In an embodiment, the SPCI server 50 may provide a list of possible service providers 31 that may provide the additional service in person to a client 21A via SPCI-app on their device 20A. The list may include information about each service provider 31A including their experience, rating(s) by other clients, area of expertise, costs of service, location, and schedule availability. A client 21A via SPCI-app on their device 20A may be able to prioritize different factors about a provider 31A in order to sort the list in an embodiment, Once selected, the SPCI server 50 may forward the appointment request to the selected service provider(s) 31 via SPCI-app on their device 30A.
The selected service provider(s) may receive client 21A information via SPCI-app on their device 30A to enable them to see service performed already by other provider(s) 31B-E and other service completed and corresponding results (laboratory tests, prescriptions filled, x-rays images). The information may be provided by a CBCS 40A indirectly or directly to service provider(s) via SPCI-app on their device 30A. Such client 21A information may not be provided until the client completes various permission(s) via their client device 20A via SPCI-app on their device 20A in an embodiment. Similarly, the newly selected or assigned service provider 31A via SPCI-app on their device 30A may be able to communicate with previous service providers 31B-E for the client 21A via SPCI-app on their devices 30B-E (subject to permissions granted by the client 21A via SPCI-app on their device 20A in an embodiment).
As noted, the newly selected or assigned service provider 31A via SPCI-app on their device 30A may be able to communicate with the client 21A via SPCI-app on their device 20A. The newly selected or assigned service provider 31A via SPCI-app on their device 30A may be able to provide other service for with the client 21A via SPCI-app on their device 20A including providing treatments, recommendations, and reviews of the client's request (or case). Staff of the newly selected or assigned service provider 31A or the provider 31A may provide paperwork required for the next service or step of service electronically via SPCI-app on their device 30A or in person. In addition, Staff of the newly selected or assigned service provider 31A or the provider 31A may collect insurance or other payment for the next service or step of service electronically via SPCI-app on their device 30A or in person. The insurance coverage and payment may be performed by the SPCI architecture 10 (via the system 80A, 80B). A service provider 31A via SPCI-app on their device 30A may be able to also assign steps of elements of a service request to other providers including their staff or related professionals. The service provider 31A or other authorized providers via SPCI-app on their device 30A may be able to assign future service appointments for remote (or virtual) or in-person directly with a client 21A via SPCI-app on their device 20A.
Similarly, a service provider 31A or other authorized provider may be able or recommend other services for remote (or virtual) or in-person via SPCI-app on their device 30A to a client 21A via SPCI-app on their device 20A. Such recommendations may be based on the client's history with the SPCI architecture 10 and may include 3rd party products related to past services and related services. As noted, an admin may be able to review activity within the SPCI architecture 10 via SPCI-app on their system 60A. In an embodiment, an admin may review complaints or other issues generated by clients 21 or service providers 31 and act to arbitrate such complaints or issues via electronic communications between the parties via SPCI-app on their device 60A. Such activity may be stored in a database stored in a CBCS 40A in an embodiment.
In an embodiment, all data related to service(s) conducted for a client 21A via SPCI architecture 10, 100C, 100D, 420, 400 may be stored in a database accessible to the client 21A via SPCI-app on their device 20A or a service provider 31A via SPCI-app on their device 30A (with client's permission(s)). In an embodiment, the data may be stored in a cloud distributed ledger system 40A (which may be a blockchain) to ensure the integrity of data. Via SPCI architecture 10, 100C, 100D, 420, 400 redundant services or related procedures may be avoided enabling a client 21A to receive faster and more accurate service(s).
When a client selects to request a new service (dental emergency 42P in an embodiment) (activity 152B of algorithm 150B of
As shown in
In an embodiment, the SPCI server 50 may direct a client 21A via SPCI-app on their device 20A to another service provider (referral) system for initial remote communication (such a nearby (based on client's device's location) emergency medical provider web or application based interface including starting a chat session (using various media as discussed) between the client 21A and emergency service provider via SPCI-app on their device 20A. In an embodiment, a SPCI server 50 may include voice activation services or engage a voice analysis system 70A to process requests or information provided by a client 21A via SPCI-app on their device 20A. The voice activation services may employ Amazon® Alexa or Google® voice processing. In an embodiment, the voice analysis system 70A may employ Amazon® Alexa or Google® voice processing.
Based on the initial triage, a SPCI server 50 may generate a new series of questions 36X, 37X (activity 166B) based on the client's 21 service request, past requests, and related data such as shown in interface 35X of
The selection of the service provider 31A may be based on the provider's availability, the client's request and the provider's associated specialization(s), schedule (whether predetermined availability schedule or real-time indicia of availability transmitted by service providers to the SPCI server using service provider devices and an associated SPCI-app), depth of queues to be processed, and past experience with the client 21A. In addition, the SPCI server 50 may evaluate the client's level of necessity for the requested service, e.g., for a medical client the SPCI server 50 may determine the client's urgency for services to address their medical need. In addition, the SPCI server 50 may compare the client's urgency for service relative to the urgency for services of other client's 20B-D having requests already in service queue(s).
Based on these factors and others a SPCI server 50 may assign a priority to the client's request and place the request in the queue of service provider's 31 via SPCI-app on their device 30A accordingly. A SPCI server 50 may report the queue status to the client 21A via SPCI-app on their device 20A as shown in interface 35AA of
In an embodiment, a client 21A via SPCI-app on their device 20A may be presented with a list of possible service providers to select to perform their requested service. The service provider list may include information about the provider including feedback from other clients in the system, professional qualifications, availability, cost(s) of service, and other service-related information.
When a client requests service via SPCI-app on their device 20A (activity 152C) it may be forwarded to a service provider (activity 174C of algorithm 150C) via SPCI-app on their device 30A in an embodiment after appropriate processing. In an embodiment, when a client 21A via SPCI-app on their device 20A requests service (initiates emergency—activity 152C), the SPCI server 50 may triage the request as noted (activity 154C). In an embodiment, other client 21A information about the client as related to the service request may be provided by expert systems 70B, and other provider systems 70A. For example, in the context of a dental service consultation with a dental professional, patient brushing and flossing habits, metrics and performance evaluation conveyed to server 50 (e.g., by a third party smart toothbrush provider system 70A, directly from a smart toothbrush device in digital communication with the user's device, or via importation into the user's SPCI-app from other systems or applications implemented by the user's mobile device), in order to provide consulting professionals with additional insight into a user's oral hygiene practices. Other metrics could be provided for other service requests, such as client physical activity as recorded by their smartwatch or mobile device in an embodiment.
As also noted, a SPCI server 50 may also forward the request to an admin via SPCI-app on their device 60A for review. A SPCI server 50 may also communicate with a 3rd party payor system 80B for insurance processing, pre-billing, or verification of 3rd party coverage of the requested service(s). As noted, a SPCI server 50 may generate additional questions and collect additional data (activity 164C, 166C) via communications with a SPCI-app on a client's device 20A that may be stored (activity 172C) via CBCS 40A. The SPCI server 50 may then formulate a request (activity 168C) and forward the request to service provider via SPCI-app on their device 30A as described above (174C) based on various factors and using artificial intelligence and expert systems 70B. The use a CBCS 40A for all client 21A and service provider data 31 may enable a client 21A via SPCI-app on their device 20A to view all their information (including all tests, images, notes from service providers 31) anytime. In an embodiment, service provider 31A and client 21A via SPCI-apps on their devices 30A, 20A may be able to see the status of 3rd party coverage or payment status prior, during, or after service processing and confirm such claims or payments to prevent fraud and expedite 3rd party coverage processing and payment processing.
As shown
Based on this activity, a service provider 31A may generate an initial bill for remote interactions via SPCI-app on their device 30A (activity 178C). Then the service provider 31A via SPCI-app on their device 30A and SPCI server 50 via AI may plan method-steps to complete the service request (provide treatment) (activity 188C) and generate further billing for determined service(s) activity 192C. The service provider 31A via SPCI-app on their device 30A and SPCI server 50 may follow up on other service request including laboratory tests and prescribed medication(s) in an embodiment (activity 194C) and further update the client's records, which may be stored via the CBCS 40A (activity 196C). If the service request is complete (activity 198C), it may be closed or additional review-steps conducted by the service provider or another service provider 31A via SPCI-app on their device 30A. In an embodiment, once at least an initial resolution is achieved or a portion of the service request in complete, payment for services may be processed via payment from the client 21A via a payment system 80A or 3rd party payor system 80B, and their respective network communications interfaces 82A and 82B (activities 197C and 199C).
In an embodiment, the databases 54, 56 may employ Greenplum (www.greenplum.com), Hadoop (hadoop.apache.org) HTTP Filer Server (HFS), PostgreSQL (www.postgresql.org) software, firebase (firebase.google.com), and other software and hardware to maintain the databases 54, 56. A SPCI server 50 may also store data on one or more cloud clusters or distributed systems. The data communication module 92A may enable a SPCI server 50 to communicate over various networks using different protocols.
A device 260 is shown in
In an embodiment, the applications 292 may be a separate module. The application module 292 may process messages, displays, or pages from and generate messages, display, responses, or pages for the SPCI server 50A server 52. The storage 265 may store data provided by the SPCI server 50A server 52. The storage device 265 may comprise any convenient form of data storage and may be used to store temporary program information, queues, databases, and overhead information.
The ROM 266 may be coupled to the CPU 262 and may store the program instructions to be executed by the CPU 262, and the application module 292. The RAM 264 may be coupled to the CPU 262 and may store temporary program data, and overhead information. The user input device 272 may comprise an input device such as a keypad, touch screen, track ball or other similar input device that allows the user to navigate through menus, displays in order to operate the device 260. The display 268 may be an output device such as a CRT, LCD, touch screen, or other similar screen display that enables the user to read, view, or hear received messages, displays, or pages from the SPCI server 50A server 52.
A microphone 288 and a speaker 282 may be incorporated into the device 260. The microphone 288 and speaker 282 may also be separated from the device 260. Received data may be transmitted to the CPU 262 via a bus 276 where the data may include messages, displays, or pages received, messages, displays, or pages to be transmitted, or protocol information. The transceiver ASIC 274 may include an instruction set necessary to communicate messages, displays, or pages in architecture 10. The ASIC 274 may be coupled to the antenna 284 to communicate wireless messages, displays, or pages within the architecture 10. When a message is received by the transceiver ASIC 274, its corresponding data may be transferred to the CPU 262 via the bus 276. The data can include wireless protocol, overhead information, and pages and displays to be processed by the device 260 in accordance with the methods described herein.
The modem/transceiver 244 may couple, in a well-known manner, the device 230 to the network 16 to enable communication with a device 20A-B, 30A-B, and 60A-B. In an embodiment, the modem/transceiver 244 may be a wireless modem or other communication device that may enable communication with a device 20A-B, 30A-B, and 60A-B. The CPU 232 via the server 254 may direct communication between modem 244 and a client device 20A or other devices 30A, 40A, 50A, 60A, 70A, 80.
The ROM 236 may store program instructions to be executed by the CPU 232, server 254, or application module 252. The RAM 234 may be used to store temporary program information, queues, databases, and overhead information. The storage device 238 may comprise any convenient form of data storage and may be used to store temporary program information, queues, databases, and overhead information.
Any of the components previously described can be implemented in a number of ways, including embodiments in software. Any of the components previously described can be implemented in a number of ways, including embodiments in software. Thus, the CPU 232, server 254, application module 252, modem/transceiver 244, antenna 246, storage 238, RAM 234, ROM 236, database 248, CPU 262, application module 292, transceiver ASIC 274, antenna 284, microphone 288, speaker 282, ROM 266, RAM 264, user input 272, display 268, SPCI server 50A, CBCS 40A, 20A-D, 30A-B, 70A-D, 80A-B, 320A, 330A-C, and 60A-B, may all be characterized as “modules” herein.
The modules may include hardware circuitry, single or multi-processor circuits, memory circuits, software program modules and objects, firmware, and combinations thereof, as desired by the architect of the architecture 10 and as appropriate for particular implementations of various embodiments.
The apparatus and systems of various embodiments may be useful in applications other than a sales architecture configuration. They are not intended to serve as a complete description of all the elements and features of apparatus and systems that might make use of the structures described herein.
Applications that may include the novel apparatus and systems of various embodiments include electronic circuitry used in high-speed computers, communication and signal processing circuitry, modems, single or multi-processor modules, single or multiple embedded processors, data switches, and application-specific modules, including multilayer, multi-chip modules. Such apparatus and systems may further be included as sub-components within a variety of electronic systems, such as televisions, cellular telephones, video game consoles, personal computers (e.g., laptop computers, desktop computers, handheld computers, tablet computers, etc.), workstations, radios, video players, audio players (e.g., mp3 players), vehicles, medical devices (e.g., heart monitor, blood pressure monitor, etc.) and others. Some embodiments may include a number of methods.
It may be possible to execute the activities described herein in an order other than the order described. Various activities described with respect to the methods identified herein can be executed in repetitive, serial, or parallel fashion.
A software program may be launched from a computer-readable medium in a computer-based system to execute functions defined in the software program. Various programming languages may be employed to create software programs designed to implement and perform the methods disclosed herein. The programs may be structured in an object-orientated format using an object-oriented language such as Java or C++. Alternatively, the programs may be structured in a procedure-orientated format using a procedural language, such as assembly or C. The software components may communicate using a number of mechanisms well known to those skilled in the art, such as application program interfaces or inter-process communication techniques, including remote procedure calls. The teachings of various embodiments are not limited to any particular programming language or environment.
The accompanying drawings that form a part hereof show, by way of illustration and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
Such embodiments of the inventive subject matter may be referred to herein individually or collectively by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept, if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
The Abstract of the Disclosure is provided to comply with 37 C.F.R. § 1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In the foregoing Detailed Description, 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 to require more features than are expressly recited in each claim. Rather, inventive subject matter may be found 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.
| Number | Date | Country | |
|---|---|---|---|
| 63076315 | Sep 2020 | US |
