Patent Application
20230291837
The disclosure relates to the field of mobile device technology, specifically to the field of integrating cloud-based callback management systems with onboard software on a mobile device.
Typically, if a client calls such a business, voice prompt menu choices enable the calling client to identify the issue for which the client requires service and the client is then queued for a service agent capable of handling the identified issue. As such, it is expected that clients who identify the purpose of their call as a “billing issue” will be queued for, and connected to, a service representative with the ability to handle billing issues. Similarly, it is expected that clients who identify the purpose of their call as a “customer service issue” will be queued for, and connected to, a service representative with the ability to handle customer service issues.
There are problems with existing communications systems, such as contact centers, including the following two problems. First, the voice prompt menus that are used to channel callers to the queue for the appropriate group of service agents are frustrating to clients. It takes significant time to navigate the layered menus of voice prompts.
Second, waiting on-hold while a connection, be it a phone call, web chat, video conference, or other interaction type, is maintained in queue for connection to a service agent is also frustrating to clients.
In an effort to reduce customer exacerbation caused by having to maintain a connection while on-hold in queue, secondary queue systems have been developed. A typical secondary queue system obtains a telephone number at which the calling client can be reached when a service representative is available (i.e., a call back number). The client disconnects, and then, at the proper time, a call back system establishes a connection to the client utilizing the call back number and couples the client to an available representative without waiting on-hold in queue. One exemplary system is disclosed in U.S. Pat. No. 6,563,921 to Williams et al. which is commonly assigned with the present application.
While such a system may make the experience of waiting for a connection to a service representative less frustrating, it does not address the inconvenience of having to navigate a slow and complicated voice prompt menu to enter the queue.
What is needed is a system and various methods for providing integration of a callback cloud with mobile device software so that callback functionality becomes a transparent and consistent feature across interaction modes through the mobile device ecosystem.
Accordingly, the inventor has conceived and reduced to practice, in a preferred embodiment of the invention, a system and method for mobile device active callback integration utilizing configurable callback triggers, utilizing a callback integration engine operating on a user's mobile device that present a callback token for integration through the operating system and software applications operating on the device, wherein interacting with the callback token produces a callback object used to execute a callback when one or more callback triggering events are detected, incorporating device hardware, context, scheduling, and trust information.
A mobile device with active callback integration has been devised, comprising: a processor, a memory, and a plurality of programming instructions stored in the memory and operable on the processor; and a callback integration engine comprising a subset of the plurality of programming instructions that, when operating on the processor, cause the processor to: provide a callback token representing an interactive indicia configured for presentation throughout an operating system of the mobile device; receive interaction from a user via the callback token; retrieve callback trigger data from a database, the callback trigger data comprising at least a triggering event and a callback action; produce a callback object, the callback object comprising information associated with the callback token and the callback trigger data; obtain an indication of an occurrence of the triggering event; perform the callback action associated with the callback trigger; wherein the callback action causes the callback integration engine to: call a callback participant based on the callback object; present an incoming call prompt to the user; and connect the user and another device, when both the user and the callback participant answer their respective incoming call prompts.
A method for mobile device active callback integration is devised, comprising the steps of: providing, using a callback integration engine operating on a computing device, a callback token representing an interactive indicia for presentation throughout a software operating system; receiving interaction from a user via the callback token; retrieving callback trigger data from a database, the callback trigger data comprising at least a triggering event and a callback action; producing a callback object comprising information associated with the callback token and the callback trigger data; obtaining an indication of an occurrence of the triggering event; performing the callback action associated with the callback trigger; wherein the callback action causes the callback integration engine to perform the steps of: calling a callback participant based on the callback object; presenting an incoming call prompt to the user; and connecting the user and another device, when both the user and the callback participant answer their respective incoming call prompts.
According to an aspect of an embodiment, the callback trigger data is associated with an electronic document, wherein the electronic document has one or more embedded triggering events.
According to an aspect of an embodiment, the another device is a third-party server and wherein the callback action causes the callback integration engine to connect the user with the third-party server.
According to an aspect of an embodiment, the mobile device is connected via a communication network to one or more remote devices.
According to an aspect of an embodiment, the indication of the occurrence of the triggering event is received from at least one of the one or more remote devices.
According to an aspect of an embodiment, the callback trigger data is associated with the mobile device being within a predetermined proximity of the one or more remote devices.
According to an aspect of an embodiment, at least one of the one or more remoted devices is a low transmission power wireless beacon.
According to an aspect of an embodiment, the callback action is selected from the list of sending a text message, sending an email message, establishing a voice communication, and establishing a connection with a third-party server.
According to an aspect of an embodiment, the callback trigger data is associated with a social media interaction by the user on the mobile device.
The accompanying drawings illustrate several aspects and, together with the description, serve to explain the principles of the invention according to the aspects. It will be appreciated by one skilled in the art that the particular arrangements illustrated in the drawings are merely exemplary, and are not to be considered as limiting of the scope of the invention or the claims herein in any way.
The inventor has conceived, and reduced to practice, a system and method for intent-based active callback management utilizing callback triggers.
One or more different aspects may be described in the present application. Further, for one or more of the aspects described herein, numerous alternative arrangements may be described; it should be appreciated that these are presented for illustrative purposes only and are not limiting of the aspects contained herein or the claims presented herein in any way. One or more of the arrangements may be widely applicable to numerous aspects, as may be readily apparent from the disclosure. In general, arrangements are described in sufficient detail to enable those skilled in the art to practice one or more of the aspects, and it should be appreciated that other arrangements may be utilized and that structural, logical, software, electrical and other changes may be made without departing from the scope of the particular aspects. Particular features of one or more of the aspects described herein may be described with reference to one or more particular aspects or figures that form a part of the present disclosure, and in which are shown, by way of illustration, specific arrangements of one or more of the aspects. It should be appreciated, however, that such features are not limited to usage in the one or more particular aspects or figures with reference to which they are described. The present disclosure is neither a literal description of all arrangements of one or more of the aspects nor a listing of features of one or more of the aspects that must be present in all arrangements.
Headings of sections provided in this patent application and the title of this patent application are for convenience only, and are not to be taken as limiting the disclosure in any way.
Devices that are in communication with each other need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices that are in communication with each other may communicate directly or indirectly through one or more communication means or intermediaries, logical or physical.
A description of an aspect with several components in communication with each other does not imply that all such components are required. To the contrary, a variety of optional components may be described to illustrate a wide variety of possible aspects and in order to more fully illustrate one or more aspects. Similarly, although process steps, method steps, algorithms or the like may be described in a sequential order, such processes, methods and algorithms may generally be configured to work in alternate orders, unless specifically stated to the contrary. In other words, any sequence or order of steps that may be described in this patent application does not, in and of itself, indicate a requirement that the steps be performed in that order. The steps of described processes may be performed in any order practical. Further, some steps may be performed simultaneously despite being described or implied as occurring non-simultaneously (e.g., because one step is described after the other step). Moreover, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications thereto, does not imply that the illustrated process or any of its steps are necessary to one or more of the aspects, and does not imply that the illustrated process is preferred. Also, steps are generally described once per aspect, but this does not mean they must occur once, or that they may only occur once each time a process, method, or algorithm is carried out or executed. Some steps may be omitted in some aspects or some occurrences, or some steps may be executed more than once in a given aspect or occurrence.
When a single device or article is described herein, it will be readily apparent that more than one device or article may be used in place of a single device or article. Similarly, where more than one device or article is described herein, it will be readily apparent that a single device or article may be used in place of the more than one device or article.
The functionality or the features of a device may be alternatively embodied by one or more other devices that are not explicitly described as having such functionality or features. Thus, other aspects need not include the device itself.
Techniques and mechanisms described or referenced herein will sometimes be described in singular form for clarity. However, it should be appreciated that particular aspects may include multiple iterations of a technique or multiple instantiations of a mechanism unless noted otherwise. Process descriptions or blocks in figures should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of various aspects in which, for example, functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those having ordinary skill in the art.
“Callback” as used herein refers to an instance of an individual being contacted after their initial contact was unsuccessful. For instance, if a first user calls a second user on a telephone, but the second user does not receive their call for one of numerous reasons including turning off their phone or simply not picking up, the second user may then place a callback to the first user once they realize they missed their call. This callback concept applies equally to many forms of interaction that need not be restricted to telephone calls, for example including (but not limited to) voice calls over a telephone line, video calls over a network connection, or live text-based chat such as web chat or short message service (SMS) texting. While a callback (and various associated components, methods, and operations taught herein) may also be used with an email communication despite the inherently asynchronous nature of email (participants may read and reply to emails at any time, and need not be interacting at the same time or while other participants are online or available), the preferred usage as taught herein refers to synchronous communication (that is, communication where participants are interacting at the same time, as with a phone call or chat conversation).
“Callback object” as used herein means a data object representing callback data, such as the identities and call information for a first and second user, the parameters for a callback including what time it shall be performed, and any other relevant data for a callback to be completed based on the data held by the callback object.
Conceptual Architecture
When needed (for example, when a user manually requests a callback or when configured settings determine that a callback is needed), a user's mobile device 101 creates a session with a callback cloud 110 with a profile manager 111, resulting in a callback being required. Profile manager 111 receives initial requests to connect to callback cloud 110, and forwards relevant user profile information to a callback manager 113, which may further request environmental context data from an environment analyzer 112. Environmental context data may include (for example, and not limited to) recorded information about when a user may be suspected to be driving or commuting from work (as may be determined from device information, such as whether a “do not disturb while driving” feature has been enabled, or if the mobile device 101 is currently connected to a car audio system), or if the user may be busy for another reason, such as if they are running or working out (as may be determined from device sensor data), for example, and may be parsed from online profiles or online textual data, using an environment analyzer 112.
A callback manager 113 centrally manages all callback data, creating a callback object which may be used to manage the data for a particular callback, and communicates with an interaction manager 114 which handles requests to make calls and bridge calls, which go out to a media server 115 which actually makes the calls as requested. In this way, the media server 115 may be altered in the manner in which it makes and bridges calls when directed, but the callback manager 113 does not need to adjust itself, due to going through an intermediary component, the interaction manager 114, as an interface between the two. A media server 11′5, when directed, may place calls and send messages, emails, or connect voice over IP (“VoIP”) calls and video calls, to users over a PSTN 103 or the Internet 102. Callback manager 113 may work with a user's profile as managed by a profile manager 111, with environmental context from an environment analyzer 112 as well as (if provided) EWT information for any callback recipients (for example, contact center agents with the appropriate skills to address the callback requestor's needs, or online tech support agents to respond to chat requests), to determine an appropriate callback time for the two users (a callback requestor and a callback recipient), interfacing with an interaction manager 114 to physically place and bridge the calls with a media server 115.
An operating system (OS) 220 comprises the main software operating on mobile device 101 and providing various software-based functions such as software applications and communications. Various software applications 221 operating within (for example in an application layer not shown here but as is commonly used in various computing devices according to the standard OSI process model of computing systems) on the mobile device 101 may expose and provide access to, or interaction with, various hardware and sensor features such as to enable a user to view or calibrate sensor readings.
According to the embodiment, a callback integration engine 201 may comprise local (that is, operating on the mobile device) functionality similar to a cloud-based callback manager 113 described above, and may operate as an application or feature at the operating system level 220, running at a similar privilege level and having similar access to hardware and software functions as other applications 221 operating on mobile device 101. This enables easy installation or removal of callback integration engine 201, as it may be readily distributed via similar methods as any other software application (for example, via an application store or similar download portal). However, this may restrict the capabilities of callback integration engine 201, as it will have only indirect access to hardware features (as it will only be able to access whatever features are exposed by the operating system) and in many cases may be “sandboxed”, and prevented from directly accessing other software or information on the mobile device 201 (for example, in a sandboxed software environment such as APPLE IOS™ or similar).
According to the embodiment, a callback integration engine 201 may operate as a firmware component that directly interfaces with hardware features of mobile device 101, enabling direct control as needed while exposing desired functionality to the operating system 220 in a transparent manner (that is, the operating system may only know that a feature is available, and may not be able to determine that the feature is provided by the callback integration engine 201 rather than, for example, the baseband controller 321). This enables more direct control over device functions, such as call routing and hardware information such as sensor readings (as may be used in callback workflow processing, as described below in greater detail with reference to
Callback integration engine 201 may present an additional prompt to setup a callback 402, either through OS-based software integration with the callback integration engine operating at the OS layer 220, or as a base-level firmware feature that is natively recognized and exposed by the OS while the callback integration engine 201 operates at the firmware level 320. This added option 402 may be used to automatically request or schedule a callback, for example by providing a message to the caller requesting they call back at a predetermined time (for example, based on known availability from a user's on-device calendar), or by engaging with a callback cloud 110 to automatically arrange a callback that connects both participants. Whether or not the callback prompt 402 is presented may be configurable, such as by incorporating trust lists or zones that determine what callers may be eligible for a callback (similar to a “favorite contacts” list that may be able to call the user even when a do-not-disturb feature is enabled), or context-based configuration such as to provide a callback prompt when the user is in a meeting or otherwise scheduled as “busy” in their calendar, or when the user is driving.
Callbacks may be scheduled according to a variety of criteria, including (but not limited to) user availability as determined from preconfigured settings or known context (for example, calendar or email information such as invitation responses or verbal commitments in messages that may not have been separately entered into a calendar), user activity based on device information such as network or sensor data (such as if the device is paired to a car audio system, indicating the user is driving, or if there is significant accelerometer data that might indicate the user is in the middle of an exercise activity). Callbacks may then be scheduled to occur when the user is available or no longer indisposed, and may also incorporate availability on the part of the caller by (for example) providing them with a selection of callback options to from which to select a specific callback time. In addition to providing a callback selection on an incoming call prompt, the callback function may be exposed in other areas throughout the device's OS and applications, such as from within voicemail messages (to setup an automated callback with the caller that left the voicemail), social media apps (to setup automated callbacks with other users), or potentially any application operating on the device 201 (such as to setup an automated callback for technical support). This integrated callback operation may be consistent throughout the device's software, providing a native user experience that blends seamlessly with the other features and elements of the device's operating system and applications.
To generate, schedule, and execute callbacks, a callback object is created on the user's device 101 to represent the callback information such as scheduling, context information, user and caller information, and any additional data pertinent to the callback (for example, related interactions such as previous calls or emails exchanged with the caller, or a known call intent based on available information from the user and/or caller, such as email transcripts or voicemail messages). This callback object may be created and maintained on-device, operating locally within the callback integration engine 201 or within an application or feature of the operating system 220 of the user's device 101, enabling full callback functionality regardless of any connection to, or availability of, a callback cloud 110. In other arrangements, callback objects may be cloud-based to provide a centralized or software-as-a-service (SaaS) operation mode, for example to provide tiered or subscription-based callback functionalities offered by a callback cloud through handling of callback objects on behalf of users.
Trust and role information may include determining whether a participant has sufficient trust to be included in the callback (for example, a callback for an email conversation may not necessarily automatically include all email participants, such as to exclude receive-only email addresses that may be included in a conversation for organizational or technical purposes but which would have no place in a call and may interfere with attempts to complete a callback), individual roles or abilities such as skills or organizational departments (for example, a callback for technical support may not include an individual from sales, even if they were present in an email conversation, or a callback for an incoming call from a corporate contact may not necessarily be setup to connect that specific individual with the user and may instead find someone more suitable to address the user's needs), or other information that may be specific to individuals available to participate in a callback.
Additional information may be made available through third-party integrations such as (for example) connecting to a callback cloud 110 to retrieve information about corporate contacts such as technical support or sales, to retrieve estimate wait time (EWT) information for a contact center, or to retrieve business hours for use in scheduling the callback. For example trust information may be determined using public/private key pairs rather than configurable trust zones; in this arrangement, a participant's key may represent their unique identifier within a callback system and be compared against a known public key to determine if the caller is who they claim to be, or if they are permitted to participate in a callback. Keys may be managed and brokered by a third-party service operated by (for example) a callback cloud 110, enabling trust delegation to a centralized entity that operates as a trust broker and can see and manage many users rather than relying on any particular user to maintain complex trust and role information on their own device.
Scheduling information is also checked 803, including the user's calendar or to-do list items to determine their own availability, as well as any available scheduling cues for other callback participants such as business hours, shared calendar events, or information contained in previous interactions (for example, if the two individuals exchanged emails discussing events or timing information).
Additional device information may then be analyzed 804, including information on a user's other devices that may be useful in determining callback conditions. For example, a user may have a chat window active on their computer, wherein they are conversing with a second individual. If the user then clicks or taps on a callback button within an email conversation on their mobile device, the chat on their desktop may be analyzed to provide additional context such as topic or scheduling information that would otherwise not be known to software on the mobile device alone. This can be accomplished in a number of ways according to the particular operating systems and devices involved, for example a shared user account or profile that is logged into multiple devices may provide a connection between callback integration engine 201 and software or data on another device associated with the same account (for example, callback integration engine 201 may be granted remote access to information on another device by providing the user's account credentials). In other arrangements, a network may be used to connect between devices such as over Wi-Fi™ or BLUETOOTH™, for example as is used in APPLE AIRDROP™ or HANDOFF™ functionality to share information between devices running MACOS™ and/or IOS™ operating systems. This enables transparent information sharing between a user's devices, so information on each device may be pooled and analyzed together to ensure the callback integration engine 201 makes the most-informed decision possible.
Finally, once all available context information has been processed, a callback object is created 805 that incorporates the necessary information for the callback (such as topic, participants, and scheduling) and the conditions determined by callback integration engine 201 to be optimum for the callback (such as when all appropriate participants will be available), and is then stored and maintained so the callback can be performed when the selected conditions have been met.
Device network connection information may then be analyzed 904, to determine additional factors such as whether the device is currently connected to a car audio system (indicating that the user is driving and thus unable to take a call until they have reached a safe location and stopped operating the vehicle), whether a user's other devices are nearby for information exchange (as described above, with reference to
Once all hardware information has been analyzed, a callback object is then created 905 that accommodates the user's current activities and environment to determine a good time to execute the callback, when the user will be available and uninvolved in other activities and when the environment may be more conducive to a call.
According to embodiments, the text message sent to the mobile device 101 may contain different information depending on whether the contact center is providing an appropriate time for the mobile device user to place a subsequent inbound call to the contact center or an appropriate time when the contact center can place an outbound call to the mobile device user. For example, if the text message is providing the mobile device user with an appropriate time for a subsequent call to the contact center then the message may inform the calling party to call back the contact center immediately or within some short period of time while the wait time is low or may provide the mobile device user with a time window for when the user should call back the contact center. For instance, if the contact center is monitoring forecasted inbound call volume instead of current average wait time for calls placed in a queue waiting for available agents, then the contact center may determine that the forecasted inbound call volume between 1:30 p.m. and 2:15 p.m. is below a threshold amount. Thus, the contact center may send the mobile device user a text message informing the user to place a subsequent call to the contact center between the hours of 1:30 p.m. and 2:15 p.m.
Additionally, the text message may provide the mobile device user with an option to request another appropriate time for a callback. Furthermore, the text message may include a telephone number for the contact center. The number provided may be a number for a specific agent so that the mobile device user is immediately connected with an agent or may be a general number used for inbound calls. In some implementations, the telephone number provided in the text message may only be valid during the appropriate time indicated in the text message. The contact center may also include additional information in the text message sent to the mobile device 101. For example, in some implementations, the contact center may customize the message based on the reason the mobile device user initially called or otherwise contacted the contact center. For example, if the inbound call was placed by the mobile device user to make a payment on an account, the text message may include information (e.g., a link) on a website the user can visit to make the payment instead. It should be appreciated that the above described information may be sent on a single text message, but that more than one text message may be utilized in order to provide such information.
A callback integration engine 201 then analyzes the information available for the text message 1010 such as (for example, including but not limited to) caller ID, texter and recipient time zones, or whether the texter is a member of a trust zone in the user's settings or contact information (or a trust zone not configured by the user, such as a corporate trust zone for coworkers and colleagues). If the caller is eligible, a callback token is associated with text message data 1012. If the user is untrusted, such as a blocked user or suspected “spam” number, the text message may be passed to the OS layer unmodified 1014. When received by the OS layer, the text messages is then displayed as an incoming notification as usual 1016, with a callback token (if available) used to place an additional callback button within the interface using the native OS and text notification user experience (UX) design. This provides an integrated automated callback functionality that is transparently incorporated into device features in a manner consistent with the operating system's UX and familiar to the user, blending the new functionality with the rest of the device features. It should be further appreciated that this mode of operation may function whether the callback integration engine 201 is operating at the firmware 320 or OS 220 level, as many mobile operating systems such as ANDROID™ and IOS™ allow for applications to integrate with communication features such as phone dialers and incoming call notification prompts. If/when the user chooses to select the callback button, the mobile device user and a contact center agent may be connected according to the method described above in
Callbacks may be scheduled according to a variety of criteria, including (but not limited to) user availability as determined from preconfigured settings or known context (for example, calendar or email information such as invitation responses or verbal commitments in messages that may not have been separately entered into a calendar), user activity based on device information such as network or sensor data (such as if the device is paired to a car audio system, indicating the user is driving, or if there is significant accelerometer data that might indicate the user is in the middle of an exercise activity). In some implementations, the text message received at the mobile device 101 may comprise a suggested appropriate time for the mobile device user to make a subsequent inbound call or an appropriate time when the mobile device user can anticipate to receive an outbound call from the contact center. Callbacks may then be scheduled to occur when the user is available or no longer indisposed, and may also incorporate availability on the part of the caller by (for example) providing them with a selection of callback options to from which to select a specific callback time. In addition to providing a callback selection on an incoming call prompt, the callback function may be exposed in other areas throughout the device's OS and applications, such as from within voicemail messages (to setup an automated callback with the caller that left the voicemail), social media apps (to setup automated callbacks with other users), or potentially any application operating on the device 201 (such as to setup an automated callback for technical support). This integrated callback operation may be consistent throughout the device's software, providing a native user experience that blends seamlessly with the other features and elements of the device's operating system and applications.
To generate, schedule, and execute callbacks, a callback object is created on the user's device 101 to represent the callback information such as scheduling, context information, user and caller information, and any additional data pertinent to the callback (for example, related interactions such as previous calls or texts exchanged with the caller, or a known call intent based on available information from the user and/or caller, such as text transcripts or voicemail messages). This callback object may be created and maintained on-device, operating locally within the callback integration engine 201 or within an application or feature of the operating system 220 of the user's device 101, enabling full callback functionality regardless of any connection to, or availability of, a callback cloud 110. In other arrangements, callback objects may be cloud-based to provide a centralized or software-as-a-service (SaaS) operation mode, for example to provide tiered or subscription-based callback functionalities offered by a callback cloud through handling of callback objects on behalf of users.
The process begins when a mobile device user 1305 (e.g., calling party) calls 1315 a contact center that is operating an adaptive cloud conversation platform 1310. The call is then answered in operation 1320. Any of the well-known telephony signaling protocols may be used to establish the voice call. A voice connection is then established 1325. The calling party may then be presented with a “hold message” by the contact center indicating that an agent is presently unavailable. Or, the calling party may be interacting with an IVR menu provided by an IVR unit, which are also well-known in the industry. The IVR menu can play an announcement and collect a response, typically either in the form of a dual tone multiple frequency (“DTMF”) signal or voice response. The menu of options is then navigated by the calling party as they deem appropriate. During this process, the IVR unit may be retrieving caller information from various information systems based on any automatic number information (“ANI”) communication in the initial call 1315.
At some point during the call, the calling party abandons the incoming call 1330. The reason they may abandon may vary. The calling party may have grown impatient waiting in a hold queue or may have been frustrated navigating the IVR menu. For example, some IVR menus may require the caller to enter information they may not readily have. The caller may not know how to respond and may hang-up during the call. Because the adaptive cloud conversation platform 1310 is not informed why the calling party abandoned the call, the contact center may use other information to aid in deciding whether the callback should occur. Thus, it is possible that the abandoned call callback process may be invoked when the calling party accidentally abandoned the call, dialed a wrong number, changed their mind, or realized they did not need to originate the call in the first place. However, the ACCP 1310 may determine from other information that the caller likely had a need to communicate, but was not willing to wait on hold.
At step 1335 the ACCP 1310 makes a determination about whether a callback needs to occur or not. The determination in step 1335 represents various tests that are carried out to determine whether an abandoned call requires a callback. In some implementations, the tests used by ACCP 1310 to determine if a callback should occur can include, but are not limited to: determination of whether the calling party's telephone number is available; determination of whether a hold time threshold has been exceeded (this reflects how long the caller has been in a hold queue); determination of whether the calling party abandoned the call in an IVR menu and at what point in the IVR menu; determination if there is a pending callback process associated with the calling party; determination of whether the call originated from a wireless or wireline number; and determining the nature of the callback call (e.g., informational, telemarketing, customer service, etc.). Based on these tests and more, ACCP 1310 can determine if a callback should occur and if the determination is that a callback should occur, ACCP 1310 can send a message which suggests a callback 1340 to the mobile device 1305. The message may be in the form of an email, text message, instant message, chatbox message, voice or video call, and/or the like.
The mobile device 1305 can receive the suggested callback message from ACCP 1310. Then a callback integration engine 201 can analyze the message data, add a callback token to be displayed in the native application operating on mobile device 1305 with which the suggested callback message was received, and create a callback object comprising callback information associated with mobile device user and the callback recipient at step 1345. For example, if the suggested callback message was sent via email, then an interactive callback button may be displayed in the email application which when selected by the mobile device user causes the callback integration engine 201 to create a callback object and connect the two or more parties when certain callback criteria have been met. At process 1350 the mobile device user selects the callback button and a callback call is placed between the mobile device 1305 and contact center via ACCP 1310, wherein the call is answered 1355 and callback integration engine 201 reestablishes the voice call 1360 and connects the two or more parties.
Mobile device 1400 may be similar to the mobile device 101 described above with the same or similar hardware and software components (referring to
According to the embodiment, remote device 1420 may be configured for detecting various triggering events and communicate with mobile device 1400. In some implementations, remote device 1420 may comprise a beacon that transmits signals to local devices. For example, Bluetooth beacons, WiFi beacons, near-field communication (NFC), radio-frequency identification (RFid). In other implementation, a remote device 1420 may not be needed to perform third-party callbacks. In some implementations, remote device 1420 may comprise an interface to observe or detect a callback trigger. For example, if the callback trigger is the verification of a user's geolocation information, the interface may be an interface to obtain a user's geolocation data. As another example, if the callback trigger is an input on remote device 1420, the interface may be a keyboard, button, switch, dial, etc. In some implementations, remote device 1420 may receive, retrieve, or otherwise obtain authentication data associated with a user or the user's mobile device. In some implementations, the authentication data may be stored on mobile device 1400, in third-party server 1430, in an authentication server, and/or in callback cloud 110 in a user profile.
According to the embodiment, third-party server 1430 may be configured to communicate with mobile device 1400 and perform third-party callback actions requested by mobile device 1400. The user may be presented with callback token which the user can interact with (e.g., push, tap, swipe, etc.) and when interacted with causes callback integration engine 1410 to create a callback object. Trigger module 1415 may be configured to receive an indication that the callback token has been interacted with and determine if a callback trigger is associated with the callback token. If there is an associated callback trigger, then the callback trigger information can be applied to the created callback object such that when remote device 1420 or mobile device 1400 observe or detect the associated callback trigger, the callback will be executed between the user's mobile device and another device based on the callback trigger configuration. In some implementations, the other device may be a third-party.
For example, a user may be trying to schedule transportation from an airport with a taxi service, but the user is unsure of when exactly he will need the taxi because it can be hard to know if a flight will be on schedule, how long it will take to disembark the plane, and then grab his luggage, all of which needs to be done before he needs the taxi. The user may be speaking on his mobile device with a taxi service representative or interacting with a taxi service online via a webpage or mobile device application when callback integration engine 1410 presents a callback token on the display of mobile device. The user can click on the callback token which automatically creates a callback object, collects the necessary information for the callback object and stores the information in the callback object, and applies an callback trigger to the callback object. Continuing with the transportation example, the callback trigger may be a geolocation based trigger wherein at the airport is a remote device 1420 which detects the presence (e.g., low energy transmission connection such as Bluetooth) of the user mobile device and executes a callback between the user and the taxi service by connecting the user's mobile device with a third-party server associated with the taxi service.
According to some embodiments, mobile device 1400 may also display a list or one or more types of callback triggers for the user to choose from. The callback triggers may be of various types. For example, callback triggers may be linked to user authentication such as via biometric authentication, wherein remote device 1420 is a biometric sensor or input system and biometric data may comprise any physical or behavioral human characteristics that are unique to an individual such as, for example, fingerprints, voiceprints, eye scans, gait, typing cadence, etc. In some implementations, a third-party can define and configure callback triggers.
The callback trigger may be associated with a determination that the remote device 1420 or mobile device 1400 has entered a geographical location, using a global positioning system (GPS) component of remote device 1420 or mobile device 1400. For example, if remote device 1420 is a wireless key fob on the user's luggage, the location may be the luggage claim area of the airport.
The callback trigger may be associated with a social media interaction by the user on the user's mobile device 1400. For example, instead of using a key fob as a remote device on his luggage the user could set up a callback trigger which determines the user's location based on social media check-ins (e.g., John Doe has checked in at SEA-TAC airport) and/or metadata associated with social media posts (e.g., location and time metadata associated with posted photos or text).
The callback trigger may be an input command on remote device 1420. In this situation, a user can provide input at remote device 1420 (e.g., entering a password). In such cases, the provided input may be associated with mobile device such as a device identifier. The callback trigger may comprise a pre-defined time range (e.g., particular date and/or time of day) during which the callback trigger is supposed to occur. The callback trigger may include one or a combination of callback triggers.
The callback trigger may be associated with an electronic document. The electronic document may comprise one or more callback triggers that cause a callback to be executed when a user has completed some task or action associated with the electronic document. For example, a lease agreement may require a user signature and be electronically sent (e.g., via email) to the user wherein the lease agreement is associated with an callback trigger that occurs when the user applies their e-signature to the lease agreement. Another example scenario includes two coworkers collaborating on a project wherein the first coworker creates a callback trigger event to occur when the second coworker reads and adds comments to the most recent draft of the project. In this scenario, when the second coworker has submitted his comments, his mobile device 1400 receives an indication of the callback trigger occurring and executes a callback between the first and second coworker. An entity and/or third-party may be able to upload documents and triggers to callback integration engine 1410, remote device 1420, third-party servers 1430, and/or callback cloud 110. An entity and/or third-party can create documents and triggers via an interface such as via a web browser. Once callback triggers are created for an electronic document, the one or more callback triggers may be inserted into the electronic document. For example, the one or more callback triggers may be inserted in headers of the digital file for the electronic document or embedded within the body of the electronic document within the digital file.
According to various implementations, each callback trigger created defines at least a triggering event and a callback action to be performed in response to the triggering event. The callback action can include, but is not limited to, sending a text message to a defined entity, sending an email message to a defined entity, establishing a voice communication (e.g., using a PSTN or VoIP) with a defined entity, polling the user of the mobile device, establishing a connection with a third-party server or service, and/or the like. It should be appreciated that the callback action may provide information to the defined entity and/or third party in receipt of the resulting communication regarding the mobile device user. For example, a user's name and contact information may be provided in a situation where the callback action is an email communication.
The triggering event for each of the one or more callback triggers may be further defined by one or more additional criteria. The additional criteria can include, but is not limited to, time or date criteria, user-based criteria, location based criteria, schedule based criteria, contextual and/or environmental criteria, and/or any combination thereof. In this way, the callback triggers can be customized to end users, locations, times, context, etc. For instance, a callback trigger may be defined as the occurrence of a defined user action at a defined trigger point during a defined time of day or on a data within a range of dates.
The determination of whether mobile device 1400 and remote device 1420 are within a pre-determined distance relative to each other may be made in various ways. In some instances, the determination may be made by broadcasting a connection request with a low transmission power so that only devices within a certain proximity may receive the connection request. If the connection request is responded to, then it may be determined that mobile device 1400 and remote device 1420 are within proximity to each other. In such cases, the broadcasting may be done by either mobile device 1400 or remote device 1420. In some implementations, the broadcast connection request may include an identifier of either remote device 1420 or mobile device 1400 such that when the identifier is received by either device it may be used to determine if the two devices are within proximity of each other.
In other implementations, the determination of the proximity of the two devices may be based on whether mobile device 1400 and remote device 1420 are both connected to the same WiFi network. In such cases, a network identifier (e.g., service set identifier) of a local network may be sent to mobile device which can compare the received network identifier with the network identifier associated with the currently connected network to determine proximity.
A third-party entity can create callback triggers to be associated with callbacks, callback objects, and/or callback tokens. Third-party callback triggers can allow the user mobile device to configure a third-party callback to be performed after an indication of the occurrence of a callback trigger event is detected. In some implementations, the callback trigger event may be detected by one or more remote devices 1420 such as beacons or sensors configured to receive and transmit various information using one or more communication protocols known to the those with skill in the art. For example, beacons and/or sensors may include, but are not limited to, near-field-communication (NFC) beacons, Wi-Fi networks, Bluetooth, radio-frequency identification, LiDar, cameras, microphones, thermal sensors, pressure sensors, biometric sensors (e.g., fingerprint scanner, eye scanner, etc.), GPS systems, and/or the like. In some implementations, a determination may be made if the user mobile device and beacon/sensor are within a pre-determined proximity to each other. If they are within proximity and if the mobile device receives the indication of occurrence (e.g., a message) from the beacon, callback integration engine 1410 may perform the third-party callback. The mobile device may perform the third-party callback by opening an application on the user mobile device and sending a third-party callback request to a third-party server 1430. The callback action associated with a third-party callback trigger may comprise routing information indicating where to direct the user during the callback (e.g., a URL, an IP address of a third-party server, phone number, routing number, extension number, contact information of an individual, etc.). In this way, a mobile device user's need to request third-party services conveniently and accurately is facilitated.
As a next step 1502, a user or third-party entity can configure created callback triggers based on additional callback trigger criteria. In some implementations, a third-party callback trigger may be triggered via social media information such as, for example, a user's location as determined by a social media check-in at a location or geotagging metadata associated with posted images or text on a social media application(s). In some implementations, a third-party event may be triggered by sensor data gathered from a user's mobile device such as, for example, device location (e.g., GPS coordinates), audible context data (e.g., user speech, background sounds and noise, etc.) recorded by a microphone on the mobile device, and other device data.
In some implementations, a callback trigger may be associated with an electronic document. The electronic document may be associated with a third-party and configured by an individual associated therewith. Electronic document callback trigger events may instruct callback integration engine 1410 to perform a callback action during consumption of the electronic document by the mobile device user. For example, a mortgage broker may require the user to read and sign a document as part of the mortgage process and apply an event trigger to the document, wherein when the user signs the document a callback is automatically executed by callback integration engine 1410 which connects the user and the mortgage broker.
As part of the configuration step, one or more callback triggers may be logically linked to specific callback tokens that can be presented to the user of mobile device 1400. For example, a callback token may appear when a user's receives a telephone call while they are streaming videos on their mobile device, wherein the callback token is specifically linked to callback triggers associated with the media player application on the user's mobile device. For example, media player specific callback triggers may be configured to execute callbacks when the media being played is put on pause or otherwise stopped. In such an scenario, callback integration engine 1410 can receive application data from application stored and operating on the user's mobile device to detect the occurrence of one or more callback triggers.
As a last step 1503, the created and configured callback trigger may be stored in a database of callback cloud 110, in third-party server 1430, and/or in the memory of mobile device 1400.
At step 1603, callback integration engine 1410 applies the callback trigger data to the callback object. Application of the callback trigger data to the callback object provides the callback object with the triggering event information, the callback action to be performed, and any other configurable criteria which may or may not be present in the callback trigger data. Once applied, the callback object comprises all the information necessary to execute a callback between the user of the mobile device and another device and/or third-party when callback integration engine 1410 detects the one or more triggering events associated with the callback object. At step 1604 callback integration engine 1410 receives, observes, and/or detects an indication of an occurrence of a callback trigger. For example, a callback trigger may be based on proximity to a specific location as indicated by the network connection between mobile device 1400 and remote device 1420 (e.g., Bluetooth beacon, etc.), wherein verification of a local network identifier is used as an indication of occurrence for the callback trigger.
In some implementations, the indication of occurrence may be associated with a software application operating on mobile device 1400 wherein an application stored and operating on the user's mobile device share information with callback integration engine 1410 in order to detect the occurrence of one or more callback trigger events. For example, a user may use a fitness application on their mobile device while they are exercising to track their performance and the user may have created a callback trigger specific to the fitness application wherein the callback trigger instructs a callback object to schedule a callback for thirty minutes after the fitness application has been closed, which allows the user enough time to get showered and changed before having to participate in callback. In such a scenario, the fitness application may share application state information (i.e., when the application was closed) with callback integration engine 1410 to be able to the callback trigger.
In some implementations, the indication of occurrence may be associated with some action or condition associated with an electronic document which has one or more callback triggers integrated into it. For example, electronic document callback triggers may include a trigger point and an action such as a pre-defined point where which a user scrolls to or past causes a triggering event or a point where user input is applied (e.g., initials, e-signature, confirmation of understanding, etc.) and when applied causes a triggering event.
At step 1605, callback integration engine 1410 performs the callback action associated with the callback trigger when a triggering event has been detected at step 1604. In some implementations, the callback action is associated with connecting the user of the mobile device with a third-party entity such as third-party server 1430. In some implementations, the callback action is associated with connecting the mobile device to another device.
A mobile device user can interact with presented callback token. This user interaction 1705 is received, retrieved, or otherwise obtained at callback integration engine 1410. Responsive to the user interaction, callback integration engine 1410 can create a callback object. Callback integration engine 1410 then requests callback trigger data 1710 from trigger module 1415 which may comprise a database for storing a plurality of callback trigger data. Each callback trigger stored in the database may comprise at least a triggering event and a callback action to be performed when the event is detected. In some embodiments, the callback token may be logically linked to one or more callback triggers. In such embodiments, the user interaction provides callback integration engine 1410 with an indication of the one or more callback triggers that may be associated with the token. Trigger module 1415 receives the request for callback trigger data, obtains the appropriate callback trigger data and sends the callback trigger data 1715 callback integration engine 1410. Callback integration engine 1410 can apply the callback trigger data to the callback object such that when a triggering event associated with the callback object is detected by callback integration engine 1410 (or in some embodiments detected by trigger module 1415) then the callback action associated with the callback trigger can be performed at the direction of callback integration engine 1410.
Once the callback trigger data has been applied to the callback object, the system operates waits for an indication (e.g., detection) of a triggering event. In this and other embodiments, a remote device 1420 is present and configured to detect one or more triggering events and send an indication of a triggering event 1720 to the callback integration engine 1410. In some embodiments, the remote device 1420 is a beacon capable of transmitting and receiving wireless signals such as a Bluetooth beacon, wireless key fob, WiFi, RFID, NFC, and/or the like. In some embodiments, the triggering event is associated with mobile device 1400 and remote device 1420 being within proximity to each other. In such an embodiment, the indication of triggering event may be a message that is communicated from the remote device 1420 to mobile device 1400 or from the mobile device 1400 to remote device 1420. For example, the message may be a ping packet sent via a wireless network or protocol.
In some implementations, a remote device 1420 is not necessary for the system to perform mobile device active callback integration with callback triggers. In such implementations, the callback triggers may be related to triggering events that occur on the mobile device 1400 such as, for example, using installed mobile application data on the mobile device at triggering events or triggering events embedded in electronic documents that the mobile device 1400 user interacts with on his or her device as described above.
Callback integration engine 1410 receives the indication of a triggering event from either remote device 1420 or from the mobile device 1400 itself and performs the callback action 1725 associated with the callback trigger applied to the callback object. In this exemplary embodiment, the callback action to be performed is connecting the mobile device user with a third-party server 1430 so that the user can receive services provided by the third-party server. To perform the callback action callback integration engine 1410 may establish a connection 1730 with the mobile device and establish a connection 1735 with the third-party server 1430. The connection may be made using a suitable communication network such as the Internet or a cell phone network. As a last step, callback integration engine 1410 bridges the callback participants 1740 (e.g., mobile device and third-party server) once a connection has been established to each participant of the callback.
Hardware Architecture
Generally, the techniques disclosed herein may be implemented on hardware or a combination of software and hardware. For example, they may be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, on an application-specific integrated circuit (“ASIC”), or on a network interface card.
Software/hardware hybrid implementations of at least some of the aspects disclosed herein may be implemented on a programmable network-resident machine (which should be understood to include intermittently connected network-aware machines) selectively activated or reconfigured by a computer program stored in memory. Such network devices may have multiple network interfaces that may be configured or designed to utilize different types of network communication protocols. A general architecture for some of these machines may be described herein in order to illustrate one or more exemplary means by which a given unit of functionality may be implemented. According to specific aspects, at least some of the features or functionalities of the various aspects disclosed herein may be implemented on one or more general-purpose computers associated with one or more networks, such as for example an end-user computer system, a client computer, a network server or other server system, a mobile computing device (e.g., tablet computing device, mobile phone, smartphone, laptop, or other appropriate computing device), a consumer electronic device, a music player, or any other suitable electronic device, router, switch, or other suitable device, or any combination thereof. In at least some aspects, at least some of the features or functionalities of the various aspects disclosed herein may be implemented in one or more virtualized computing environments (e.g., network computing clouds, virtual machines hosted on one or more physical computing machines, or other appropriate virtual environments).
Referring now to
In one embodiment, computing device 10 includes one or more central processing units (CPU) 12, one or more interfaces 15, and one or more busses 14 (such as a peripheral component interconnect (PCI) bus). When acting under the control of appropriate software or firmware, CPU 12 may be responsible for implementing specific functions associated with the functions of a specifically configured computing device or machine. For example, in at least one embodiment, a computing device 10 may be configured or designed to function as a server system utilizing CPU 12, local memory 11 and/or remote memory 16, and interface(s) 15. In at least one embodiment, CPU 12 may be caused to perform one or more of the different types of functions and/or operations under the control of software modules or components, which for example, may include an operating system and any appropriate applications software, drivers, and the like.
CPU 12 may include one or more processors 13 such as, for example, a processor from one of the Intel, ARM, Qualcomm, and AMD families of microprocessors. In some embodiments, processors 13 may include specially designed hardware such as application-specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), field-programmable gate arrays (FPGAs), and so forth, for controlling operations of computing device 10. In a specific embodiment, a local memory 11 (such as non-volatile random access memory (RAM) and/or read-only memory (ROM), including for example one or more levels of cached memory) may also form part of CPU 12. However, there are many different ways in which memory may be coupled to system 10. Memory 11 may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, and the like. It should be further appreciated that CPU 12 may be one of a variety of system-on-a-chip (SOC) type hardware that may include additional hardware such as memory or graphics processing chips, such as a QUALCOMM SNAPDRAGON™ or SAMSUNG EXYNOS™ CPU as are becoming increasingly common in the art, such as for use in mobile devices or integrated devices.
As used herein, the term “processor” is not limited merely to those integrated circuits referred to in the art as a processor, a mobile processor, or a microprocessor, but broadly refers to a microcontroller, a microcomputer, a programmable logic controller, an application-specific integrated circuit, and any other programmable circuit.
In one embodiment, interfaces 15 are provided as network interface cards (NICs). Generally, NICs control the sending and receiving of data packets over a computer network; other types of interfaces 15 may for example support other peripherals used with computing device 10. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, graphics interfaces, and the like. In addition, various types of interfaces may be provided such as, for example, universal serial bus (USB), Serial, Ethernet, FIREWIRE™, THUNDERBOLT™, PCI, parallel, radio frequency (RF), BLUETOOTH™, near-field communications (e.g., using near-field magnetics), 802.11 (Wi-Fi), frame relay, TCP/IP, ISDN, fast Ethernet interfaces, Gigabit Ethernet interfaces, Serial ATA (SATA) or external SATA (ESATA) interfaces, high-definition multimedia interface (HDMI), digital visual interface (DVI), analog or digital audio interfaces, asynchronous transfer mode (ATM) interfaces, high-speed serial interface (HSSI) interfaces, Point of Sale (POS) interfaces, fiber data distributed interfaces (FDDIs), and the like. Generally, such interfaces 15 may include physical ports appropriate for communication with appropriate media. In some cases, they may also include an independent processor (such as a dedicated audio or video processor, as is common in the art for high-fidelity A/V hardware interfaces) and, in some instances, volatile and/or non-volatile memory (e.g., RAM).
Although the system shown in
Regardless of network device configuration, the system of the present invention may employ one or more memories or memory modules (such as, for example, remote memory block 16 and local memory 11) configured to store data, program instructions for the general-purpose network operations, or other information relating to the functionality of the embodiments described herein (or any combinations of the above). Program instructions may control execution of or comprise an operating system and/or one or more applications, for example. Memory 16 or memories 11, 16 may also be configured to store data structures, configuration data, encryption data, historical system operations information, or any other specific or generic non-program information described herein.
Because such information and program instructions may be employed to implement one or more systems or methods described herein, at least some network device embodiments may include nontransitory machine-readable storage media, which, for example, may be configured or designed to store program instructions, state information, and the like for performing various operations described herein. Examples of such nontransitory machine-readable storage media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as optical disks, and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM), flash memory (as is common in mobile devices and integrated systems), solid state drives (SSD) and “hybrid SSD” storage drives that may combine physical components of solid state and hard disk drives in a single hardware device (as are becoming increasingly common in the art with regard to personal computers), memristor memory, random access memory (RAM), and the like. It should be appreciated that such storage means may be integral and non-removable (such as RAM hardware modules that may be soldered onto a motherboard or otherwise integrated into an electronic device), or they may be removable such as swappable flash memory modules (such as “thumb drives” or other removable media designed for rapidly exchanging physical storage devices), “hot-swappable” hard disk drives or solid state drives, removable optical storage discs, or other such removable media, and that such integral and removable storage media may be utilized interchangeably.
Examples of program instructions include both object code, such as may be produced by a compiler, machine code, such as may be produced by an assembler or a linker, byte code, such as may be generated by for example a JAVA™ compiler and may be executed using a Java virtual machine or equivalent, or files containing higher level code that may be executed by the computer using an interpreter (for example, scripts written in Python, Perl, Ruby, Groovy, or any other scripting language).
In some embodiments, systems according to the present invention may be implemented on a standalone computing system. Referring now to
In some embodiments, systems of the present invention may be implemented on a distributed computing network, such as one having any number of clients and/or servers. Referring now to
In addition, in some embodiments, servers 32 may call external services 37 when needed to obtain additional information, or to refer to additional data concerning a particular call. Communications with external services 37 may take place, for example, via one or more networks 31. In various embodiments, external services 37 may comprise web-enabled services or functionality related to or installed on the hardware device itself. For example, in an embodiment where client applications 24 are implemented on a smartphone or other electronic device, client applications 24 may obtain information stored in a server system 32 in the cloud or on an external service 37 deployed on one or more of a particular enterprise's or user's premises.
In some embodiments of the invention, clients 33 or servers 32 (or both) may make use of one or more specialized services or appliances that may be deployed locally or remotely across one or more networks 31. For example, one or more databases 34 may be used or referred to by one or more embodiments of the invention. It should be understood by one having ordinary skill in the art that databases 34 may be arranged in a wide variety of architectures and using a wide variety of data access and manipulation means. For example, in various embodiments one or more databases 34 may comprise a relational database system using a structured query language (SQL), while others may comprise an alternative data storage technology such as those referred to in the art as “NoSQL” (for example, HADOOP CASSANDRA™, GOOGLE BIGTABLE™, and so forth). In some embodiments, variant database architectures such as column-oriented databases, in-memory databases, clustered databases, distributed databases, or even flat file data repositories may be used according to the invention. It will be appreciated by one having ordinary skill in the art that any combination of known or future database technologies may be used as appropriate, unless a specific database technology or a specific arrangement of components is specified for a particular embodiment herein. Moreover, it should be appreciated that the term “database” as used herein may refer to a physical database machine, a cluster of machines acting as a single database system, or a logical database within an overall database management system. Unless a specific meaning is specified for a given use of the term “database”, it should be construed to mean any of these senses of the word, all of which are understood as a plain meaning of the term “database” by those having ordinary skill in the art.
Similarly, most embodiments of the invention may make use of one or more security systems 36 and configuration systems 35. Security and configuration management are common information technology (IT) and web functions, and some amount of each are generally associated with any IT or web systems. It should be understood by one having ordinary skill in the art that any configuration or security subsystems known in the art now or in the future may be used in conjunction with embodiments of the invention without limitation, unless a specific security 36 or configuration system 35 or approach is specifically required by the description of any specific embodiment.
In various embodiments, functionality for implementing systems or methods of the present invention may be distributed among any number of client and/or server components. For example, various software modules may be implemented for performing various functions in connection with the present invention, and such modules may be variously implemented to run on server and/or client components.
The skilled person will be aware of a range of possible modifications of the various embodiments described above. Accordingly, the present invention is defined by the claims and their equivalents.
Priority is claimed in the application data sheet to the following patents or patent applications, each of which is expressly incorporated herein by reference in its entirety: Ser. No. 17/987,392Ser. No. 16/985,093Ser. No. 16/583,967Ser. No. 16/542,57762/820,19062/828,133
| Number | Date | Country | |
|---|---|---|---|
| 62820190 | Mar 2019 | US | |
| 62828133 | Apr 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16583967 | Sep 2019 | US |
| Child | 16985093 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17987392 | Nov 2022 | US |
| Child | 18180081 | US | |
| Parent | 16985093 | Aug 2020 | US |
| Child | 17987392 | US | |
| Parent | 16542577 | Aug 2019 | US |
| Child | 16583967 | US |
