Omnichannel context sharing

Abstract

The session shared data system accesses the first communication between the user and the support agent on the first communication channel and stores the communication data related to the first communication in a session shared data object. The session shared data system accesses the subsequent communication between the user and the second agent on the second communication channel, receives queries related to the subsequent communication, and sends a response to the query to the second agent's device. The response includes the communication data stored in the session shared data object.

Description

Technical Field

[0001] Embodiments disclosed herein generally relate to data storage. More specifically, but not by way of limitation, the systems and methods disclosed herein describe session-sharing data objects accessible by a plurality of asynchronous communication sessions.

Background Art

[0002] A positive customer experience in customer support is critical to the success of an enterprise. As face-to-face interactions decrease, demand for improving online solutions for customer support is increasing.

Brief Description of Drawings

[0003] To facilitate easy identification of the description of any particular element or act, the most significant digit or digits in a reference numeral indicate the figure number in which the element is first introduced. [Figure 1] Fig. 1 is a schematic diagram of a networked environment to which the present disclosure may be applied, in accordance with some examples. [Figure 2] Fig. 2 is a diagram showing the architecture of a session-sharing data system according to an example embodiment. [Figure 3] Fig. 3 is a diagram showing a process for generating a session-sharing data object according to an example. [Figure 4] Fig. 4 is an example of a conversation on a listing network platform that provides conversation context in customer support using a session-sharing data system. [Figure 5] Fig. 5 is a schematic representation of a machine in the form of a computer system in which a set of instructions may be executed to cause the machine to perform one or more of the methods described herein, in accordance with some examples, illustrating one aspect of the subject matter according to one embodiment. [Figure 6] Fig. 6 is a block diagram showing a software architecture in which some examples may be implemented. [Modes for carrying out the invention]

[0004] The following paragraphs describe systems and methods for sharing customer support information across multiple customer support communication channels. Improving customer support performance requires inferring conversational context based on aggregated insights across multiple communication channels. Traditionally, each communication between a customer and a support agent runs as a separate workflow session. Therefore, different sessions are independent of each other, and interactions between different communication channels are relatively limited. Exchanging data across diverse communication channels can be limited by channel-specific and product-specific nuances. In some examples, a product is a specific set of workflows tailored to serve a particular purpose. Multiple products may operate within a single communication channel. Different channels may use different labels for the same data type. Aligning various products into a consistent interface for shared data generation often presents both technical and operational challenges. Furthermore, it is common for different products to be associated with different databases for data storage. When the underlying databases are separated, building a unified, scalable strategy for data sharing becomes a technical challenge.

[0005] Embodiments disclosed herein describe a session-sharing data system that enables a workflow session, including communication between a customer and a human or bot support agent, to store shareable data in a data store, and further enables other workflow sessions associated with the customer to retrieve desired information from the data store. Such communication may take place over a communication channel, which is a platform where users, such as customers and support agents, communicate. Examples include email, messaging platforms with artificial intelligence bots or human users, and telephone calls.

[0006] The session-sharing data system enables the sharing of information between different workflow sessions belonging to the same user. This allows users to transition between different communication channels without losing context. Exemplary use cases include information aggregation and task handover across communication channels. In the first use case, when a support agent is resolving a particular user's issue, information collected throughout the user's entire history may be visually presented to the support agent to facilitate problem identification. In the second use case, a support agent may want to hand over several tasks to an automated process and then retrieve the information collected after the tasks are completed. The information shared with the support agent in the first use case is likely to be general information capturing basic customer support attributes such as the reason for contact, reservation information, and case identification number. The information used by the support agent and automated process in the second use case is likely to be tailored to a very specific interface that only the support agent and automated process can recognize. Therefore, it is important to distinguish between these two types of data in the session-sharing data system. Further details regarding the session-sharing data system are described in the following paragraphs.

[0007] Networked computing environment

[0008] Figure 1 is a block diagram illustrating an exemplary networked system 102 for facilitating listing services (e.g., listing of goods or services for sale or barter, and purchasing of goods or services) over a network. The networked system 102 includes a plurality of user systems 104, each user system 104 hosting a plurality of applications, including a client application 106 and other applications 108. Each client application 106 is communicably coupled to instances of other client applications 106 (e.g., those hosted on other user systems 104, respectively), a server system 112, and a third-party server 114) via one or more communication networks, including a network 110 (e.g., the Internet). The client application 106 can also communicate with other locally hosted applications 108 using an application programming interface (API).

[0009] Each user system 104 may include multiple user devices that are connected to each other for exchanging data and messages, such as a mobile device 116 and a computer client device 118.

[0010] The client application 106 interacts with other client applications 106 and the server system 112 via the network 110. The data exchanged between client applications 106 and between client applications 106 and the server system 112 includes functions (e.g., commands to invoke functions) and payload data (e.g., text, audio, video, or other multimedia data).

[0011] In some exemplary embodiments, the client application 106 is a booking application for temporary stays or experiences at hotels, motels, or residences managed by other end users (e.g., posting end users who own a house and rent out the whole house or individual rooms). In some implementations, the client application 106 includes various components that can present information to the end user and communicate with the networked system 102. In some embodiments, if the booking application is included in a computer client device 118, the application is configured to provide a user interface and at least some functions locally, and is configured to communicate with the networked system 102 to obtain data or processing capabilities not available locally as needed (e.g., access to a database of items for sale, user authentication, verification of payment methods). Conversely, if the booking application is not included in the computer client device 118, the computer client device 118 can use its web browser to access e-commerce sites (or variations thereof) hosted on the networked system 102.

[0012] The server system 112 provides server-side functions to the client application 108 via the network 110. Certain functions of this networked system 102 may be described herein as being performed by the client application 106 or by the server system 112, but the placement of specific functions within the client application 106 or within the server system 112 may be a design choice. For example, technically, it may be preferable to initially deploy certain technologies and functions within the server system 112 and later migrate those technologies and functions to the client application 106 when the user system 104 has sufficient processing power.

[0013] The server system 112 supports various services and operations provided to the client application 106. These operations include sending data to the client application 106, receiving data from the client application 106, and processing data generated by the client application 106. In some examples, this data includes message content, client device information, geographical location information, reservation information, transaction information, and message content. Data exchange within the networked system 102 is invoked and controlled by functions available through the user interface (UI) of the client application 106.

[0014] Next, specifically regarding the server system 112, the Application Programming Interface (API) server 120 is coupled to the application server 122 and provides a programmatic interface to the application server 122, making the functions of the application server 122 accessible to client applications 106, other applications 108, and third-party servers 114. The application server 122 is communicatively coupled to the database server 124, facilitating access to the database 126, which stores data related to the interactions processed by the application server 122. Similarly, the web server 128 is coupled to the application server 122 and provides a web-based interface to the application server 122. For this purpose, the web server 128 processes incoming network requests using the Hypertext Transfer Protocol (HTTP) and several other related protocols.

[0015] The Application Programming Interface (API) server 120 sends and receives interaction data (e.g., commands and message payloads) between the application server 122, the user system 104 (e.g., the interactive client application 106 and other applications 108), and the third-party server 114. Specifically, the Application Programming Interface (API) server 120 provides a set of interfaces (e.g., routines and protocols) that the client application 106 and other applications 108 can use to call the functions of the application server 122. The Application Programming Interface (API) server 120 exposes various functions supported by the application server 122, including account registration and login functions.

[0016] The application server 122 hosts the listing network platform 130 and the session sharing data system 132, each containing one or more modules or applications, and can be implemented as hardware, software, firmware, or any combination thereof. The application server 122 is shown coupled with the database server 124, which facilitates access to one or more information storage repositories or databases 126.

[0017] The listing network platform 130 provides users accessing the networked system 102 with a number of publishing and listing services. Although the listing network platform 130 is shown in Figure 1 as constituting part of the networked system 102, in alternative embodiments, it is understood that the listing network platform 130 may constitute part of a separate and independent web service from the networked system 102. The listing network platform 130 may be hosted on dedicated or shared server machines that are connected in a communicative manner. The listing network platform 130 provides a number of publishing and listing mechanisms that enable sellers (also called “first users,” posting users, or hosts) to list (or publish information about) goods or services for sale or barter, and buyers (also called “second users,” search users, or guests) to express interest in purchasing or bartering the goods or services, and to complete a transaction (e.g., an exchange).

[0018] In some examples, the listing network platform 130 also includes an automation platform. This automation platform is used to provide customer service functions to assist sellers or buyers. In some examples, the automation platform includes reusable actions and conditions that allow operators to create workflows. This automation platform may be supported by a central workflow engine, such as a state machine. In some examples, the automation platform has three main components: an event orchestrator, a workflow engine, and an action store. The event orchestrator is an input / output (I / O) layer that encapsulates communication channel-specific idiosyncrasies. The workflow engine is responsible for managing and executing all workflows driven by the platform. The action store handles all action executions requested by the workflow engine.

[0019] The session-sharing data system 132 generates session-sharing data objects that store communication data between the customer and the support agent during a workflow session. These session-sharing data objects are accessible by other workflow sessions associated with that customer to improve the conversational context in the customer support functionality on the listing network platform 130. Further details regarding the session-sharing data system 132 are described below.

[0020] Figure 2 shows the architecture of a session sharing data system 132 according to an example embodiment. An operator of the session sharing data system 132 (for example, an operator of the listing network platform 130) can use a user interface (UI) tool 220 to generate workflow schemas such as workflow schema 1 (202) and workflow schema 2 (210) for executing workflow sessions (for example, session execution 1 (216) and session execution 2 (218)).

[0021] A workflow schema (e.g., 202, 210) is a structured representation of a workflow, describing a set of tasks, arbitrary independence, and potential outcomes. The schema provides a blueprint for how a process or set of tasks should be executed from start to finish. A workflow schema includes nodes, transitions, and start and end points. A node is a unit of individual work within a workflow. Each node represents a specific action. Illustrative actions include read actions (data fetching or machine learning prediction) and write actions (such as sending a message or performing a refund). Transitions define how a process moves from one node to the next. Transitions can be based on given conditions or constraints in the session-shared data system 132. Each workflow further has a defined start point and a set of end points.

[0022] A workflow session is a runtime object that contains information enabling execution of a workflow schema. A workflow session defines processes on the listing network platform 130, such as canceling an existing reservation, adding a new listing, or reporting an issue related to a listing. A workflow session typically includes session variables, a workflow schema, an action dispatcher, and state management. Session variables include a number of runtime variables generated by specific nodes during runtime. Session variables are managed and retained by the workflow session, and are made accessible to subsequent nodes. As described above, a workflow schema is the blueprint of a given workflow. A workflow session retains the workflow schema in memory and needs to continuously reference the schema to determine actions that require execution. The action dispatcher dispatches tasks to an action store and obtains the corresponding results. A workflow session needs to use state management to save the current session state as a checkpoint in a database. When the session is resumed by a subsequent user request, the session state can be regenerated by loading data from the database.

[0023] A session shared data (SSD) object 1 (212) is a data object that contains public information related to a workflow session. In some examples, the SSD object 1 (212) has two main attributes: domain-specific data and product-specific data. Domain-specific data includes universal attributes common to multiple products within a domain. For example, domain-specific data includes a reservation identification number, a contact reason, a ticket identification number, payment data, and the like. Product-specific data includes any non-general information that the communication session intends to disclose. In some examples, product-specific data is specific to the communication channel itself.

[0024] In some examples, domain-specific data is defined in an Interface Description Language (IDL) file, such as APACHE THRIFT. Product-specific data may similarly be defined in an IDL file, or the structure of product-specific data may be dynamically defined by an operator of the session-shared data system 132 or the listing network platform 130 via the UI tool 220. In some examples, both domain-specific and product-specific data have explicit interfaces for establishing a common protocol between data generators and data consumers. This interface presents a clearly defined structure that specifies the set of fields included in the domain-specific or product-specific data and the data type of each field (e.g., string, integer, object, etc.). A common protocol across diverse products is essential to ensure that product-specific peculiarities are removed. For example, a chatbot product might internally refer to the listing identifier as "listingNumber," while an interactive voice response (IVR) product might refer to it as "listingID." Therefore, it is important to establish standardized abstractions across products when generating SSD objects. This allows operators to avoid the complexity of the internal logic of other products when accessing data such as listing identifiers. Domain-specific data may have the same interface for different products within the same domain, while product-specific data may have different interfaces for different products.

[0025] The SSD data object includes metadata such as product name, communication channel, and / or session ID derived from the workflow session that generates the SSD object. Each SSD object can be updated by a plurality of workflows when the workflow is used in the same session. The life cycle of an SSD object may exceed the lifetime of the workflow session that generated the SSD object. Once generated, the SSD object continues to persist and can be referenced by other workflow sessions. In some examples, generation of the SSD object follows a "create when first update" approach, which means that the session shared data system 132 checks whether an SSD object already exists for updating the SSD data object for a workflow session. If no SSD object exists, a new record (e.g., a new SSD object) is created in the data store 214. In some examples, each workflow session (e.g., session execution 1 (216)) can only write to one SSD object (e.g., SSD object 1 (212)). However, one workflow session can read from a plurality of SSD objects.

[0026] SSD objects are strongly typed objects with explicit schemas and data definitions. At runtime, SSDs can be treated as weakly typed objects by the session-shared data system 132. For example, at runtime, an SSD object can be treated as a Javascript Object Notation (JSON) object and as a single field in the data store 214. In particular, domain-specific and product-specific data can be stored in weakly typed data objects such as strings. If domain-specific data, product-specific data, and the metadata of the SSD object were each treated as separate fields, the session-shared data system would require multiple interfaces and multiple data storage solutions. However, because SSD objects are treated as a single field (as weakly typed objects), only the interfaces for the various data types within the SSD object need to be modified, thereby improving the efficiency of the session-shared data system 132.

[0027] Operators of the session shared data system 132 can generate workflow schema 1 (202) and workflow schema 2 (210) using the UI tool 220. Session execution 1 (216) is executed using workflow schema 1 (202) and generates and updates SSD object 1 (212). Session execution 1 (216) can access the SSD object from other workflow sessions under the same user. Session execution 2 (210) executes a workflow session using workflow schema 2 (210). Session execution 2 (210) can fetch data for SSD object 1 (212) from the data store 214.

[0028] Figure 3 shows a process 300 for generating SSD objects in several examples. One or more processors in a computing device or system, such as the processor of the Listing Network Platform 130, the processor of the Session Shared Data System 132, the processor of the Networking System 102, the processor of the User System 104, the processor of the Server System 112, or any combination thereof, can perform the operations in process 300.

[0029] In operation 302, the computing system accesses a first communication between the user and the agent over a first communication channel. In some examples, the user is a customer of the listing network platform 130, and the agent is a support agent for the listing network platform 130. The support agent may be a human agent or a bot agent operating on a messaging platform, an IVR platform, or other suitable platform.

[0030] In some examples, the first communication is accessed from a first workflow session on a central workflow engine, such as session execution 1(216) shown in Figure 2. The first workflow session includes a first workflow schema, such as workflow schema 1(202). For example, the first communication may be an inquiry from a customer seeking assistance in setting up a new listing on the listing network platform 130. The first communication may take place on a messaging platform channel with a bot support agent. To assist in setting up the new listing, the bot support agent initiates a first workflow session defined using the first workflow schema.

[0031] In operation 304, the computing system stores communication data related to the first communication in an SSD object (e.g., SSD object 1(212)). The SSD object stores metadata, domain-specific data, and product-specific data related to the first workflow session. For example, the SSD object stores user actions generated during the first workflow session. Following the example above, if a user uploaded a photo of their listing as part of the first workflow session, the SSD object would store that photo. In some examples, the SSD object is generated based on the first workflow schema. For example, the workflow schema can instruct the workflow session to generate or update SSDs by action. In some examples, the workflow schema includes an update action that updates an existing SSD object if one exists, and generates a new SSD object if no SSD object associated with a particular workflow session exists. The update action can be incorporated into any node in the workflow schema. The workflow schema can further control what is stored in the SSD object by constructing a key-value map extracted from runtime variables generated during the workflow session execution. For example, if it is necessary to store a reservation identification number at a specific stage, the schema inserts a node that triggers the update action described above.

[0032] In operation 306, the computing system accesses subsequent communication between the user and the second agent over a second communication channel. In some examples, the first communication channel is of a different type than the second communication channel. For example, based on the example above, the first communication channel may be a messaging platform with a first bot support agent, and the second communication channel may be an interactive voice response (IVR) telephone call with a second bot support agent. The subsequent communication is accessed from a second workflow session on the central workflow engine (e.g., session execution 2(218)). In this example, the second workflow session may be started at any point after the start of the first workflow session. For example, if during the first communication the user wishes to complete the listing procedure for their reservation at another time and requests to do so by telephone call rather than through the messaging platform, the next step is started by the second agent via the IVR platform as part of the second workflow session.

[0033] In operation 308, the computing system receives queries related to subsequent communications. For example, a query may include a request for access to an SSD object (e.g., fetching SSD object 1(212)). For example, an operator of the session shared data system 132 may query the data store 214 for one or more SSD objects associated with a user using computer programming code, such as SQL or any suitable programming language. In some examples, the session shared data system 132 includes a query interface for filtering and sorting fields of metadata for SSD objects, domain-specific data attributes for a single SSD object, and product-specific data attributes. In some examples, the session shared data system 132 queries the data store 214 automatically. For example, based on a second workflow session, the session shared data system 132 accesses predefined queries for automatically querying the data store 214.

[0034] In operation 310, the computing system receives a response to the query. The response to the query is an SSD object that matches the query's filter or search parameters. The retrieved SSD object is associated with the same user.

[0035] In operation 312, the computing system sends the response to the query to the device of the second agent. For example, the retrieved SSD object is provided as input to a subsequent node in the second workflow session. The second workflow session utilizes the SSD object data to assist the user. For example, using the example above, the IVR product retrieves the SSD object from the messaging platform product. This SSD object is passed to a subsequent node in the second workflow session and used to determine whether a particular help article has already been suggested to the user, so as not to redundantly recommend the same article.

[0036] Figure 4 illustrates an example of a conversation on a listing network platform 130 that provides a conversation context in customer support using a session sharing data system 132, according to an embodiment. User interface 402 is a telephone call transcript of a conversation between a customer and a support agent. The telephone call is a first type of communication channel, and the support agent is a first support agent. In the transcript, the customer requests that the conversation continue on a different communication channel. User interface 404 is the continuation of the conversation between the customer and a different support agent. This continuation of the conversation takes place on a second type of communication channel, different from the first type of communication channel. For example, the continuation of the conversation takes place on a messaging platform. The support agent is a second support agent. The session sharing data system 132 queries the data store 214 for the most recent SSD objects associated with the customer. The data store 214 provides the SSD objects generated during the first workflow session related to the telephone call to the second workflow session related to the messaging platform. Therefore, different support agents can access SSD objects generated during a workflow session related to a phone call and use the information in those SSD objects to efficiently assist the customer, eliminating the need for the customer to repeatedly explain the context to different support agents.

[0037] Machine Architecture

[0038] Figure 5 is a schematic diagram showing a machine 502 in the form of a computer system, on which instructions 504 (e.g., software, programs, applications, applets, apps, or other executable code) can be executed to cause the machine 502 to perform one or more of the methodologies described herein, according to several examples. For example, instructions 504 can cause the machine 502 to perform one or more of the methods described herein. Instructions 504 transform a general-purpose, unprogrammed machine 502 into a specific machine 502 programmed to perform the functions described and illustrated herein in the manner described herein. The machine 502 can operate as a standalone device or can be coupled to other machines (e.g., networked). In a network deployment, the machine 502 can operate as a server machine or client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. Machine 502 includes, but is not limited to, server computers, client computers, personal computers (PCs), tablet computers, laptop computers, netbooks, set-top boxes (STBs), personal digital assistants (PDAs), entertainment media systems, cellular telephones, smartphones, mobile devices, wearable devices (e.g., smartwatches), smart home devices (e.g., smart appliances), other smart devices, web appliances, network routers, network switches, network bridges, or any machine capable of executing instruction 504 sequentially or in other manner to perform one or more of the methodologies discussed herein. Furthermore, although a single machine 502 is illustrated, the term “machine” should also be interpreted to include a collection of multiple machines that individually or jointly execute instruction 504 to perform one or more of the methodologies discussed herein.For example, machine 502 may include user system 104 or any of the multiple server devices that make up part of server system 112. In some examples, machine 502 may also include both a client system and a server system, where certain operations of a particular method or algorithm may be performed on the server side and certain operations may be performed on the client side.

[0039] Machine 502 may include a processor 506, memory 508, and input / output (I / O) components 510, which may be configured to communicate with each other via a bus 512. In one example, the processor 506 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a composite instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processing unit (DSP), an application-specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any appropriate combination thereof) may include, for example, processors 514 and processor 514 that execute instruction 504. The term “processor” is intended to include multicore processors, which include two or more independent processors (sometimes called “cores”) that can execute instructions simultaneously. Figure 5 shows multiple processors 506, but machine 502 may include a single processor with a single core, a single processor with multiple cores (e.g., a multicore processor), multiple processors with a single core, multiple processors with multiple cores, or any combination thereof.

[0040] Memory 508 includes main memory 518, static memory 520, and a storage unit 522, both of which are accessible from the processor 506 via bus 512. Main memory 518, static memory 520, and storage unit 522 store instructions 504 that implement one or more of the methodologies or functions described herein. Instructions 504 may also be present, fully or partially, in main memory 518, static memory 520, machine-readable media 524 in storage unit 522, in at least one of the processors 506 (e.g., in the processor's cache memory), or any combination thereof, during execution by machine 502.

[0041] The I / O component 510 may include a wide variety of components for receiving inputs, providing outputs, generating outputs, transmitting information, exchanging information, capturing measurements, etc. The I / O component 510 included in a particular machine depends on the type of machine. For example, portable machines such as mobile phones may include touch input devices or other input mechanisms, while headless server machines are unlikely to include such touch input devices. It is understood that the I / O component 510 may include many other components not shown in Figure 5. In various examples, the I / O component 510 may include user output components 526 and user input components 528. The user output component 526 may include visual components (e.g., displays such as plasma display panels (PDPs), light-emitting diode (LED) displays, liquid crystal displays (LCDs), projectors, or cathode ray tubes (CRTs)), acoustic components (e.g., speakers), tactile components (e.g., vibration motors, resistance mechanisms), other signal generators, etc. The user input components 528 may include alphanumeric input components (e.g., a keyboard, a touchscreen configured to receive alphanumeric input, a photo-optical keyboard, or other alphanumeric input components), pointing input components (e.g., a mouse, a touchpad, a trackball, a joystick, a motion sensor, or other pointing device), haptic input components (e.g., a physical button, a touchscreen that provides touch position and touch pressure or touch gesture, or other haptic input components), voice input components (e.g., a microphone), and the like.

[0042] In further examples, the I / O component 510 may include a biometric component 530, a motion component 532, an environmental component 534, or a location component 536, etc. For example, the biometric component 530 may include a component that detects an expression (e.g., hand gestures, facial expressions, vocal expressions, body gestures, or eye tracking), a component that measures a biosignal (e.g., blood pressure, heart rate, body temperature, sweating, or electroencephalography), or a component that identifies a person (e.g., voice recognition, retinal recognition, facial recognition, fingerprint recognition, or electroencephalography-based identification), etc. The biometric component may include a brain-machine interface (BMI) system that enables communication between the brain and an external device or machine. This can be achieved by recording brain activity data, converting the data into a computer-readable format, and using the resulting signals to control the device or machine.

[0043] Examples of BMI (Body-Machine Interface) technology include the following: • A brain-machine interface (BMI) based on electroencephalography (EEG), which records electrical activity in the brain using electrodes placed on the scalp. • An invasive BMI that uses electrodes surgically implanted in the brain. Optogenetics BMI uses light to control the activity of specific nerve cells in the brain.

[0044] Any biometric data collected by biometric components will only be captured and stored with the user's consent and deleted upon the user's request. Furthermore, such biometric data may only be used for very limited purposes, such as identity verification. To ensure the limited and authorized use of biometric information and other personally identifiable information (PII), access to such data will be restricted to authorized personnel only, if any. Any use of such biometric data may be strictly limited to identity verification purposes and will not be shared or sold to third parties without the user's express consent. In addition, appropriate technical and organizational measures will be implemented to ensure the security and confidentiality of such sensitive information.

[0045] The motion component 532 includes an acceleration sensor component (e.g., an accelerometer), a gravity sensor component, and a rotation sensor component (e.g., a gyroscope).

[0046] The environmental components 534 include, for example, one or more cameras (with still image / photo and video capabilities), an illuminance sensor component (e.g., a photometer), a temperature sensor component (e.g., one or more thermometers for detecting ambient temperature), a humidity sensor component, a pressure sensor component (e.g., a barometer), an acoustic sensor component (e.g., one or more microphones for detecting ambient noise), a proximity sensor component (e.g., an infrared sensor for detecting nearby objects), a gas sensor (e.g., a gas detection sensor for detecting hazardous gas concentrations for safety or for measuring airborne pollutants), or other components that can provide indications, measurements, or signals corresponding to the surrounding physical environment.

[0047] Regarding the camera, the user system 104 may include a camera system that includes, for example, a front camera located on the front of the user system 104 and a rear camera located on the back of the user system 104. The front camera may be used, for example, to capture still images and videos of the user of the user system 104 (e.g., "selfie"), and these may be enhanced by the enhanced data (e.g., filters) described above. The rear camera may be used, for example, to capture still images and videos in a more conventional camera mode, and these images may also be enhanced by the enhanced data. In addition to the front and rear cameras, the user system 104 may include a 360-degree camera for capturing 360-degree photos and videos.

[0048] Furthermore, the camera system of the user system 104 may include, for example, a dual rear camera including a main camera and a depth-sensing camera, or a triple, quad, or penta camera configuration on the front and rear. These multiple camera systems may include, for example, a wide-angle camera, an ultra-wide-angle camera, a telephoto camera, a macro camera, and a depth sensor.

[0049] The position component 536 includes a position sensor component (e.g., a GPS receiver component), an altitude sensor component (e.g., an altimeter or barometer that detects atmospheric pressure from which altitude can be derived), a direction sensor component (e.g., a magnetometer), and the like.

[0050] Communication can be implemented using a wide variety of technologies. The I / O component 510 may further include a communication component 538, which is operable to connect machine 502 to network 540 or device 542 via its respective coupling or connection. For example, communication component 538 may include a network interface component or other suitable device for interface with network 540. In further examples, communication component 538 may include wired communication components, wireless communication components, cellular communication components, near-field communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components. Device 542 may be another machine or a wide variety of peripherals (e.g., USB-coupled peripherals).

[0051] Furthermore, the communication component 538 may include components that detect identifiers or are capable of operating to detect identifiers. For example, the communication component 538 may include a radio frequency identification (RFID) tag reader component, an NFC smart tag detection component, an optical reader component (e.g., an optical sensor for detecting one-dimensional barcodes such as Universal Product Code (UPC) barcodes, Quick Response (QR) codes, Aztec codes, Data Matrix, Dataglyph®, MaxiCode, PDF417, Ultra Code, UCC RSS-2D barcodes, and other optical codes), or an acoustic detection component (e.g., a microphone for identifying tagged audio signals). In addition, various types of information can be derived via the communication component 538, such as location by Internet Protocol (IP) geolocation, location by Wi-Fi® signal triangulation, and location by detection of NFC beacon signals that can indicate a specific location.

[0052] Various memories (e.g., main memory 518, static memory 520, and memory of processor 506) and storage unit 522 may store one or more instruction sets and data structures (e.g., software) that implement or are used by one or more methodologies or functions described herein. When these instructions (e.g., instruction 504) are executed by processor 506, they trigger various actions to implement examples of the present disclosure.

[0053] Instruction 504 may be transmitted or received on the network 540 using a transmission medium via a network interface device (e.g., a network interface component included in communication component 538) using one or more well-known transmission protocols, such as the Hypertext Transfer Protocol (HTTP). Similarly, instruction 504 may be transmitted or received using a transmission medium via coupling to device 542 (e.g., peer-to-peer coupling).

[0054] Software Architecture

[0055] Figure 6 is a block diagram 602 showing a software architecture 604 in which several examples can be implemented, and which can be installed on one or more of the devices described herein. In this example, the software architecture 604 is supported by hardware such as a machine 606, which includes a processor 608, memory 610, and I / O components 612. In this example, the software architecture 604 can be conceptualized as a stack of layers, each layer providing a specific function. The software architecture 604 includes layers such as an operating system 614, a library 616, a framework 618, and an application 620. Operationally, the application 620 invokes an API call 622 through the software stack and receives a message 624 in response to the API call 622.

[0056] The operating system 614 manages hardware resources and provides common services. The operating system 614 includes, for example, the kernel 626, services 628, and drivers 630. The kernel 626 acts as an abstraction layer between the hardware and other software layers. For example, the kernel 626 provides functions such as memory management, processor management (e.g., scheduling), component management, networking, and security settings. Services 628 can provide other common services to other software layers. Drivers 630 are responsible for controlling or interfaceing with the underlying hardware. For example, drivers 630 may include display drivers, camera drivers, BLUETOOTH® or BLUETOOTH® Low Energy drivers, flash memory drivers, serial communication drivers (e.g., USB drivers), Wi-Fi® drivers, audio drivers, power management drivers, etc.

[0057] Library 616 provides a common low-level infrastructure used by application 620. Library 616 may include system libraries 632 (e.g., the C standard library) that provide, for example, memory allocation functions, string manipulation functions, mathematical functions, etc. Furthermore, library 616 may include API libraries 634 such as media libraries to support various media formats (e.g., Moving Picture Experts Group-4 (MPEG4), Advanced Video Coding (H.264 or AVC), Moving Picture Experts Group Layer-3 (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codecs, Joint Photographic Experts Group (JPEG or JPG), or Portable Network Graphics (PNG)), graphics libraries such as the OpenGL framework used to render two-dimensional (2D) and three-dimensional (3D) graphic content on the display, database libraries such as SQLite that provide various relational database functions, and web libraries such as WebKit that provide web browsing functionality. Library 616 may also include a wide variety of other libraries 636 to provide numerous other APIs to application 620.

[0058] Framework 618 provides a common high-level infrastructure used by application 620. For example, Framework 618 can provide various graphical user interface (GUI) functions, high-level resource management, and high-level location services. Framework 618 can also provide a wide range of other APIs that can be used by application 620, some of which may be specific to a particular operating system or platform.

[0059] For example, application 620 may include a home application 638, a contacts application 640, a browser application 642, a book reader application 644, a location application 646, a media application 648, a messaging application 650, a game application 652, and many other applications such as third-party applications 654. Application 620 is a program that performs functions defined in the program. Various programming languages ​​may be used to generate one or more applications 620, such as object-oriented programming languages ​​(e.g., Objective-C, Java, or C++) or procedural programming languages ​​(e.g., C or assembly language), and they may be structured in various ways. In a particular example, a third-party application 654 (e.g., an application developed by an entity other than the platform vendor using the ANDROID® or iOS® Software Development Kit (SDK)) may be mobile software that runs on a mobile operating system such as iOS®, ANDROID®, WINDOWS® Phone, or other mobile operating systems. In this example, the third-party application 654 can invoke the API call 622 provided by the operating system 614 to facilitate the functionality described above.

[0060] "Carrier signal" refers to any intangible medium that can store, encode, or transmit instructions, including, for example, digital or analog communication signals to facilitate the communication of instructions. Instructions may be transmitted or received over a network using a transmission medium.

[0061] "Client device" refers to any machine that interfaces to a communication network to obtain resources from one or more server systems or other client devices. A client device is not limited to a mobile phone, desktop computer, laptop computer, personal digital assistant (PDA), smartphone, tablet, ultrabook, netbook, laptop, multiprocessor system, microprocessor-based or programmable consumer electronics, game console, set-top box, or any communication device that a user may use to access the network.

[0062] "Communication network" can mean, for example, an ad hoc network, intranet, extranet, virtual private network (VPN), local area network (LAN), wireless LAN (WLAN), wide area network (WAN), wireless WAN (WWAN), metropolitan area network (MAN), the Internet, part of the Internet, part of the public switched telephone network (PSTN), general telephone service (POTS) network, cellular telephone network, wireless network, Wi-Fi® network, other types of networks, or a combination of two or more of these. For example, a network or part of a network may include a wireless or cellular network, and the coupling may implement a Code Division Multiple Access (CDMA) connection, a Global System for Mobile communications (GSM) connection, or other types of cellular or wireless coupling. In this example, the coupling may implement any of the following: Single Carrier Radio Transmission Technology (1xRTT), Evolution-Data Optimized (EVDO), General Packet Radio Service (GPRS), Enhanced Data rates for GSM Evolution (EDGE), 3G as defined by the 3rd Generation Partnership Project (3GPP), 4G networks, Universal Mobile Telecommunications System (UMTS), High Speed ​​Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standards, other long-range protocols as defined by other standards bodies, or a variety of other data transfer technologies.

[0063] A “Component” refers to a device, physical entity, or logic whose boundaries are defined, for example, by a function or subroutine call, branch point, API, or other technique that provides the division or modularization of a particular processing or control function. A Component may combine with other Components through its interface to perform a machine process. A Component may be a packaged functional hardware unit designed to be used with other Components, or typically part of a program that performs a particular function of the associated function. A Component may be either a software component (e.g., code implemented on a machine-readable medium) or a hardware component. A “Hardware Component” is a tangible unit capable of performing a particular operation and may be configured or arranged in a particular physical form. In various examples, one or more computer systems (e.g., a standalone computer system, a client computer system, or a server computer system) or one or more hardware components of a computer system (e.g., a processor or a group of processors) may be configured as a hardware component by software (e.g., an application or application portion) and may operate to perform the particular operations described herein. Hardware components may also be implemented mechanically, electronically, or in any appropriate combination thereof. For example, a hardware component may include dedicated circuitry or logic permanently configured to perform a specific operation. A hardware component could be a special-purpose processor such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC). A hardware component may also include programmable logic or circuitry temporarily configured by software to perform a specific operation. For example, a hardware component may include software executed by a general-purpose processor or other programmable processor.When configured by such software, a hardware component becomes a specific machine (or a specific component of a machine) specifically adapted to perform the configured function, and is no longer a general-purpose processor. The decision of whether to implement a hardware component mechanically, with dedicated and permanently configured circuitry, or with temporarily configured circuitry (e.g., circuitry configured by software), may be driven by cost and time considerations. Therefore, the term “hardware component” (or “hardware implementation component”) should be understood to encompass tangible entities, which may be physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed). Considering the example of a temporarily configured hardware component, each hardware component does not need to be configured or materialized at any given time. For example, if a hardware component includes a general-purpose processor that becomes a special-purpose processor when configured by software, that general-purpose processor may be configured at different times, each time as a different special-purpose processor (e.g., including different hardware components). Thus, software may configure a particular processor or set of processors as a particular hardware component at one time, and at another time as that processor or set of processors as different hardware components. Hardware components can provide information to and receive information from other hardware components. Therefore, the hardware components described can be considered to be communicatively coupled to one another. When multiple hardware components exist simultaneously, communication can be achieved through signal transmission between two or more hardware components (e.g., via appropriate circuits and buses). In examples where multiple hardware components are configured or materialized at different points in time, communication between these hardware components can be achieved, for example, through the storage and retrieval of information in a memory structure accessible to the multiple hardware components.For example, a hardware component may perform an operation and store the output of that operation in a memory device to which it is communicably coupled. Another hardware component may then access the memory device at a later time, retrieve the stored output, and process it. Hardware components may also initiate communication with input or output devices and perform operations on resources (e.g., a collection of information). Various operations of the exemplary methods described herein may be performed at least partially by one or more processors temporarily configured by software, or by one or more processors permanently configured. Such temporarily or permanently configured processors may constitute a processor implementation component that performs one or more operations or functions described herein. As used herein, “processor implementation component” refers to a hardware component implemented using one or more processors. Similarly, the methods described herein may be implemented at least partially by processors, and a particular processor or set of processors is an example of hardware. For example, at least some operations of the methods may be performed by one or more processors or processor implementation components. Furthermore, one or more processors may support the execution of the relevant operations as a cloud computing environment or as software as a service (SaaS). For example, at least some operations may be performed by a group of computers (e.g., machines including processors), and these operations may be accessible via a network (e.g., the Internet) and one or more appropriate interfaces (e.g., APIs). The execution of certain operations may reside not only within a single machine but also distributed among processors deployed across multiple machines. In some examples, a processor or processor implementation component may be located in a single geographical location (e.g., a home environment, an office environment, or a server farm). In other examples, a processor or processor implementation component may be distributed across multiple geographical locations.

[0064] "Computer-readable storage medium" refers to both mechanical storage mediums and transmission mediums, for example. Therefore, this term includes both storage devices / mediums and carrier waves / modulated data signals. The terms "machine-readable medium," "computer-readable medium," and "device-readable medium" are synonymous and may be used interchangeably in this disclosure.

[0065] "Mechanical storage medium" refers to, for example, one or more storage devices and media that store executable instructions, routines, and data (e.g., centralized or distributed databases, and associated caches and servers). Therefore, the term includes, but is not limited to, solid memory, and optical and magnetic media inside or outside processors. Specific examples of mechanical storage medium, computer storage medium, and device storage medium include, for example, non-volatile memory including semiconductor memory devices such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), FPGAs, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms "mechanical storage medium," "device storage medium," and "computer storage medium" are synonymous and may be used interchangeably in this disclosure. The terms "mechanical storage medium," "computer storage medium," and "device storage medium" expressly exclude carrier waves, modulated data signals, and other media, at least some of which are encompassed by the term "signaling medium."

[0066] A "non-temporary computer-readable storage medium" refers to, for example, a tangible medium capable of storing, encoding, or transmitting instructions for execution by a machine.

[0067] "Signal medium" means any intangible medium capable of storing, encoding, or transmitting instructions for execution by a machine, including, for example, digital or analog communication signals for facilitating the communication of software or data. The term "signal medium" should be interpreted to include any form, such as modulated data signals, carrier waves, etc. "Modulated data signal" means a signal in which one or more of its properties are set or modified to encode information within the signal. The terms "transmission medium" and "signal medium" are synonymous and may be used interchangeably in this disclosure.

[0068] "User device" refers, for example, to a device that is accessed, controlled, or owned by a user and that the user uses to perform actions or interactions (including interactions with other users or computer systems) on that user device.

Claims

1. It is a method, The process of accessing a first communication between a user and an agent on a first communication channel, The process involves storing the communication data related to the first communication in a session shared data object, The process of accessing subsequent communication between the user and the second agent on a second communication channel, The process of receiving a query related to the subsequent communication, A method comprising the steps of sending a response to the query to the device of the second agent, wherein the response includes communication data stored in the session shared data object.

2. The method according to claim 1, wherein the first communication is accessed from a first workflow session on a central workflow engine, and the first workflow session causes a series of processes to be executed.

3. The method according to claim 2, wherein the first workflow session includes a first workflow schema, and the first workflow schema includes a structured representation of the workflow session.

4. The method according to claim 3, wherein the session shared data object is generated using the first workflow schema, and the first workflow schema includes an action for generating the session shared data object.

5. The method according to claim 2, wherein the subsequent communication is accessed from a second workflow session on the central workflow engine, and the second workflow session was initiated after the first workflow session.

6. The method according to claim 1, wherein the query includes a request to access data stored in the session shared data object.

7. The method according to claim 1, wherein the first communication channel is a different type of communication channel from the second communication channel.

8. A computing system, Processor and A memory, which, when executed by the processor, in the system, The process of accessing a first communication between a user and an agent on a first communication channel, The process involves storing the communication data related to the first communication in a session shared data object, The process of accessing subsequent communication between the user and the second agent on a second communication channel, The process of receiving a query related to the subsequent communication, A step of sending a response to the query to the device of the second agent, wherein the response includes communication data stored in the session shared data object, A computing system comprising: a memory that stores instructions for performing an operation including;

9. The computing system according to claim 8, wherein the first communication is accessed from a first workflow session on a central workflow engine, and the first workflow session causes a series of processes to be executed.

10. The computing system according to claim 9, wherein the first workflow session includes a first workflow schema, and the first workflow schema includes a structured representation of the workflow session.

11. The computing system according to claim 10, wherein the session shared data object is generated using the first workflow schema, and the first workflow schema includes an action for generating the session shared data object.

12. The computing system according to claim 9, wherein the subsequent communication is accessed from a second workflow session on the central workflow engine, and the second workflow session was initiated after the first workflow session.

13. The computing system according to claim 8, wherein the query includes a request to access data stored in the session shared data object.

14. The computing system according to claim 8, wherein the first communication channel is a different type of communication channel from the second communication channel.

15. A non-temporary computer-readable storage medium, which, when executed by a computer, the computer, The process of accessing a first communication between a user and an agent on a first communication channel, The process involves storing the communication data related to the first communication in a session shared data object, The process of accessing subsequent communication between the user and the second agent on a second communication channel, The process of receiving a query related to the subsequent communication, A non-temporary computer-readable storage medium comprising an instruction causing an operation to be performed, the step of transmitting a response to the query to the device of the second agent, wherein the response includes communication data stored in the session shared data object.

16. The non-temporary computer-readable storage medium according to claim 15, wherein the first communication is accessed from a first workflow session on a central workflow engine, and the first workflow session causes a series of processes to be executed.

17. The non-temporary computer-readable storage medium according to claim 16, wherein the first workflow session includes a first workflow schema, and the first workflow schema includes a structured representation of the workflow session.

18. The non-temporary computer-readable storage medium according to claim 17, wherein the session shared data object is generated using the first workflow schema, and the first workflow schema includes actions for generating the session shared data object.

19. The non-temporary computer-readable storage medium according to claim 16, wherein the subsequent communication is accessed from a second workflow session on the central workflow engine, and the second workflow session was initiated after the first workflow session.

20. The non-temporary computer-readable storage medium according to claim 15, wherein the query includes a request to access data stored in the session shared data object.

Images