Chat bot-based authentication of chat bots

A method for authentication of chat bots includes determining that a first chat bot is authenticated, by a server, for first session communication at a first chat session with a first chat application instance. The first chat session is hosted by a first chat service. The method includes determining authentication intent to authenticate, with the server, a second chat bot for a second session communication at a second chat session with a second chat application instance. The second chat session is hosted by a second chat service, where the first chat bot and the second chat bot simulate respective chat application instances. The method also includes providing authentication credentials, via the first chat session, to authenticate the second chat bot with the server for the second session communication.

BACKGROUND

Embodiments of the inventive subject matter generally relate to the field of communication systems and, more particularly, to communicating in chat sessions using chat bots.

Chat sessions facilitate communication between chat applications in a communication system. A user of a chat application can communicate, over a communication network, with a user of another chat application by transmitting communication to, and receiving communication from, the chat session. A chat bot can simulate a chat application to communicate with other chat applications using the chat session. The user can also have an account at a transaction server. The chat bot can be authenticated to access the user's account at the transaction server. However, authenticating additional chat bots at other chat sessions to access the user's account at the transaction server can be difficult. If access to own user account via other chat sessions is tedious and overly complicated, that may discourage the user from using other chat sessions.

DESCRIPTION OF EMBODIMENT(S)

The description that follows includes exemplary systems, methods, techniques, instruction sequences and computer program products that embody techniques of the present inventive subject matter. However, it is understood that the described embodiments may be practiced without these specific details. For instance, although some examples refer to social media services, other types of media services are contemplated, such as interactive comment sections of online news services or of other online services.

Chat sessions facilitate communication between instances of chat applications running on various devices in a communication system. A user of one instance of a chat application can communicate, over the communication system, with a user of another instance of a chat application by transmitting and receiving communication to/from the chat session. For example, the communication system facilitates the transmission of chat texts, over a communication network, between the instances of the chat applications and the chat session. The chat session, which can be hosted by a chat service, can facilitate communication between the multiple instances of the chat applications. Each chat application, such as a SLACK chat application, or a FACEBOOK MESSENGER application, can be hosted by a user device. The user device can be any type of a personal device such as a mobile phone, tablet, or other computing device.

In some cases, the communication may be between multiple instances of the same type of chat application. In other cases, the communication may involve instances of multiple different types of chat applications. Furthermore, the user can use multiple chat applications on the user device, substantially at the same time. The user device can allow multitasking execution of several applications, each of which can be in a different execution state. An application that is open on the user device is an application that can be in a running state, in a suspended/waiting state, in a blocked state, etc. Thus, the user device can have multiple chat applications open. For example, an instance of the SLACK chat application can be open in a running state on the user device, and an instance of the FACEBOOK MESSENGER chat application can be open in a suspended state on the same user device. One of the chat applications instances can be executing in a web browser on the user device, instead of as a stand-alone application.

Multiple SLACK chat application instances can communicate with each other by transmitting chat texts to, and receiving chat texts from, a SLACK chat session. The chat service can be a part of a social media service. For example, the chat service can be a SLACK chat service that is a part of a SLACK team collaboration tool, or a FACEBOOK MESSEGENGER chat service that is a part of a FACEBOOK social networking service. The chat service itself can be further hosted by a server or another type of a computing device. The user device can thus communicate (via separate chat application instances) with multiple chat sessions, each one being hosted by a different chat service.

A bot application can communicate, via a chat bot, with the chat session and simulate a chat application instance for communicating with the other chat application instances. The chat bot can send and receive chat texts from the chat session. For example, one bot application may simulate a SLACK chat application instance for communicating, using a SLACK chat bot via a SLACK chat session, with other SLACK chat application instances. Another bot application may simulate a FACEBOOK MESSENGER chat application instance for communicating, using a FACEBOOK MESSENGER chat bot via a FACEBOOK MESSENGER chat session, with other FACEBOOK MESSENGER chat application instances.

The user may have access to a chat session via a chat application instance. A method for authentication of chat bots includes determining that a first chat bot is authenticated, by a server, for first session communication at a first chat session with a first chat application instance. The first chat session is hosted by a first chat service. The method includes determining authentication intent to authenticate, with the server, a second chat bot for a second session communication at a second chat session with a second chat application instance. The second chat session is hosted by a second chat service, where the first chat bot and the second chat bot simulate respective chat application instances. The method also includes providing authentication credentials, via the first chat session, to authenticate the second chat bot with the server for the second session communication.

In some embodiments, the user can communicate, over a new chat session, with a chat bot (referred to as the new chat bot) that has not yet been authenticated to access the user's account. The bot application that hosts the new chat bot can determine whether the user uses another chat bot, at another chat session, that has been authenticated to access the user's account at the transaction server. Once the bot application determines the authenticated chat bot, the authenticated bot application can provide, via the another chat session, authentication credentials for authentication of the new chat bot. These authentication credentials can be used to authenticate the new chat bot at the new chat session to access the user account at the transaction server.

For frictionless operation, the user has the ability to leverage communication with an authenticated chat bot to authenticate additional chat bot(s) in additional chat sessions. For example, the user can communicate with an authenticated SLACK chat bot to access a user account at the transaction server. The user can also communicate with a new FACEBOOK MESSENGER chat bot, which has not been yet authenticated. The user can use the SLACK chat bot to facilitate authentication of the FACEBOOK MESSENGER chat bot for accessing the user account at the transaction server. The user does not need to separately login and/or provide a password for the FACEBOOK MESSENGER chat bot for use with the transaction server. In some embodiments, the chat application instances on the user device do not need to be placed in a different execution state when performing the authentication. In some embodiments, when performing the authentication, only the two chat application instances are used on the user device, without using additional applications. Providing of additional login and/or password information, or using additional applications can create friction, and also be insecure as the login and/or password information can be accessed by fraudulent entities. The following description, and associated Figures, illustrates various embodiments directed to the ideas listed above.

FIG. 1is a system diagram100illustrating some embodiments of a communication system where chat bots communicate with chat application instances over multiple chat sessions. In an overview of the system diagram100, a transaction bot application104hosts both a transaction chat bot102(1) and a transaction chat bot102(2). The bot application104communicates using separate chat sessions—via the transaction chat bot102(1) with a chat session106(1), and via the transaction chat bot102(2) with a chat session106(2). Each of the transaction chat bots102(1) and102(2) is associated with a single respective chat session.

The chat sessions106(1) and106(2) are hosted by separate chat services108(1) and108(2), respectively. For example, the chat service108(1) can be implemented by SLACK, and the chat service108(2) can be implemented by FACEBOOK MESSENGER. The chat services108(1) and108(2) can be hosted by social media services110(1) and110(2), respectively. For example, the FACEBOOK MESSENGER chat service108(2) can be hosted by FACEBOOK social media service110(2).

The transaction chat bots102(1) and102(2) (also referred to as “chat bots”102(1) and102(1)) can each simulate respective chat application instances when communicating, via the chat sessions106(1) and106(2), with the chat application instances112(1) and112(2), respectively. The chat application instances112(1) and112(2) can communicate with other chat application instances (not shown) via the chat session106(1) and106(2), respectively. For example, the chat application instance112(1) can transmit a chat text to the chat session106(1), where this chat text can be accessed by other chat application instance(s). The chat application instances112(1) and112(2) can be hosted by a user device114.

The user device114can also display a user interface (UI)120. The UI120can display visual elements, such as chat texts of the chat sessions106(1) and106(2). The UI120can also receive input from the user. It is noted that the user device114can also receive input from the user via other input elements, such as via a keyboard, mouse, microphone (e.g., from a voice command), among others.

The bot application104can interface with a transaction server116to provide instructions to the transaction server116and receive transaction information regarding users and/or user accounts from the transaction server116. For example, the transaction server116can provide financial services, such as a fund transfer (e.g., a transfer of a certain monetary amount), to users. The transaction server116can include transaction accounts, each of which can be associated with a user. The transaction server116can facilitate a fund transfer from the user transaction account to a merchant payment account, (i.e., associated with a merchant and in response to instructions received from the transaction bot application104(1)). The transaction server116can be implemented by PAYPAL or another online transaction system that allows users to send, accept, and request fund transfers.

It is noted that although some examples refer to using the transaction server116, the transaction bot application104, and the transaction chat bots102(1) and102(2) for payment transactions, the transaction server116can process general transactions for the user account. For example, the transaction server116can be implemented by a Software as a Service (SaaS) server that provides software services for the user device114of the user. The chat application instances112(1) can then be used to access the user account at the SaaS server to provide software services for the user device114. In some implementations, the transaction server116can interface with one or more financial institutions (not shown). The financial institutions can provide financial services to users. The financial institutions118can be implemented as banks, credit unions, other deposit-taking institutions that accept and manage deposits and make loans, and other financial service providers. In some embodiments, the financial institutions can include credit card networks, e.g., for funding transfer of money between users.

In one embodiment, the transaction bot application104can be implemented as a part of the transaction server116. The server can be implemented on a single computing device, or on multiple computing devices (e.g., using distributed computing devices or a cloud service). In another embodiment, the transaction bot application104is separate from the transaction server116. The transaction bot application104can instantiate the chat bot102(1), as well as the chat bot102(2). The transaction bot application104can access, via the chat bot102(1), chat texts that are provided to the chat session106(1) by the chat application instance112(1). Similarly, the transaction bot application104can access, via the chat bot102(2), chat texts that are provided to the chat session106(2) by the chat application instance112(2). AlthoughFIG. 1shows a single bot application104, the transaction server116can host several transaction bot applications, e.g., a separate transaction bot application for each of the chat bots102(1) and102(2).

A service or an application (such as the transaction bot application104) can be hosted by a combination of software and hardware. It is noted that the same term “hosting” is used herein to describe both software hosting and hardware hosting. When software hosting, a software service such as the chat service108, can instantiate and manage multiple chat sessions, such as the chat session106and other chat sessions. When hardware hosting, a computing device (such as a server or a user device) can provide resources such as memory, communication, and execution resources for execution of instructions.

The examples presented herein include the chat bot102(1) being authenticated to access the user account at the transaction server116. The chat bot102(2) is initially not authenticated to access the user account at the transaction server116. The chat sessions106(1) and106(2) are hosted by different chat services108(1) and108(2). Thus, the authenticated chat bot102(1) does not have access to the chat session106(2) at another chat service108(2). Instead, the chat bot102(2) needs to be authenticated for accessing the user account based on communication at the chat session106(2). The authenticated chat bot102(1) can be used to provide authentication credentials to the chat session106(1). The authentication credentials can be accessed via the chat application instance112(1) to authenticate the chat bot102(2). The authentication of the chat bot102(2) can be performed by the transaction server116, or by another server (e.g., an authentication server). For frictionless operation, the user can authenticate multiple chat bots based on authentication credentials received from an authenticated chat bot, where each of the chat bots is hosted by a different chat service.

FIG. 2is a flow diagram illustrating embodiments of operations for accessing chat session communication for transactions between chat bot applications. The method ofFIG. 2is described with reference to the systems and components described inFIG. 1(for illustration purposes and not as a limitation). The example operations can be carried out by the transaction bot application104and/or by the transaction server116. It is noted that communication via chat sessions can be accessed (e.g., transmitted and/or received) by the transaction bot application104via a respective chat bot from the transaction chat bots102(1) and102(2).

Beginning with202, the bot application determines whether a first chat bot is authenticated, by a server, for first session communication at a first chat session with a first chat application instance. With reference toFIG. 1, the bot application104determines whether the chat bot102(1) is authenticated for session communication at the chat session106(1) with the chat application instance112(1). The session communication includes communication that accesses an account, of the user, at the transaction server116. If the first chat bot is authenticated, the flow proceeds to206. If the first chat bot is not authenticated, the flow proceeds back to204.

The bot application104can determine authentication of the transaction chat bot102(1) by communicating with the transaction server116. The bot application104can determine the authentication by accessing a database that stores data entries indicating authentication of transaction chat bots with various chat sessions and/or chat application instances. For example, in some embodiments, the transaction chat bot102(1) can be authenticated for accessing user accounts of multiple users that communicate using respective chat application instances via the chat session106(1). Thus, the database can indicate that the transaction chat bot102(1) can be authenticated for multiple session communications over the chat session106(1).

At204, the bot application authenticates, with the server, the first chat bot for first session communication. With reference toFIG. 1, the bot application104authenticates, with the transaction server116, the transaction chat bot102(1) for first session communication, i.e., for communication accessing an account of the user at the transaction server116via the chat session106(1). The authentication of the first session communication can be configured for a certain duration, and only for communication between the chat bot102(1) and the chat application instance112(1) over the chat session106(1).

At206, the bot application determines authentication intent to authenticate the second chat bot for second session communication. With reference toFIG. 1, the bot application104can determine the authentication intent (for authenticating the chat bot102(2)) based on chat texts received at the chat session106(1) and accessed via the chat bot102(1), or based on chat texts received at the chat session106(2) and accessed via the chat bot102(2).FIG. 3shows one example of a chat text at300that can be accessed by the bot application104to make this determination. In some embodiments, based on the chat texts, the bot application104can also determine whether the chat application instances112(1) and112(2) are hosted by the same user device. If the bot application determines the authentication intent, the flow proceeds to210. If the bot application does not determine the authentication intent, the flow proceeds to208and then back to206. At208, the bot application continues to communicate with the first chat bot via the first session communication.

At210, the bot application provides authentication credentials, via the first chat session, to authenticate the second chat bot for the second session communication. With reference toFIG. 1, the bot application104can provide, via communication provided by the chat bot102(1) to the chat session106(1), the authentication credentials. The authentication credentials can be used by an authenticating server (such as the transaction server116or by a stand-alone server) to authenticate the chat bot102(2) for session communication at the chat session106(2) with the chat application instance112(2). Once the chat bot102(2) is authenticated, the chat application instance112(2) can provide chat texts (to the chat session106(2)) that once accessed by the chat bot102(2) and then processed by the bot application104, can instruct the bot application104to access the user account at the transaction server116.

In some embodiments, the authentication credentials can be a one-time token for use at the second chat session106(2). As shown in the example ofFIG. 3, the chat bot102(1) can provide, via the chat text310, a one-time token at318. The chat application instance112(1) can access the one-time token. The one-time token can then be communicated to the chat session106(2) via the chat application instance112(2). For example, the one-time token can be automatically copied, at the user device114, from the chat application instance112(1) (i.e., as accessed from the chat session106(1)) to the chat application instance112(2) (i.e., to be provided to the chat session106(2)). In one implementation, the user of the user device can copy the one-time token between the different chat application instances. In these examples, either the user device or the user can affect the execution state of the chat application instances112(1) and112(2) based on the type of authentication credential that is received.

In some embodiments, the authentication credentials can include a link for authenticating the second session communication. The link can be for accessing an authentication web page at the authentication server. In some embodiments, the link can reference the chat bot102(2) and/or the chat session106(2). In some embodiments, the link can be a deep link that is accessed from the chat application instance112(1) for accessing the chat application instance112(2) on the user device114. Once linked to the chat application112(2), the deep link can be used (e.g., by the user device114) to generate a new chat text for use by the chat application instance112(2). The new chat text can be a response (that references the authentication credentials) that, when provided to the chat session106(2), is accessed by the transaction server (or an authentication server) to authenticate the chat bot102(2).

In some embodiments, the transaction server116can initiate authentication of the chat bot102(2). The authentication credentials provided by the transaction chat bot102(1) to the chat session106(10can include a prompt for confirmation of the authentication of the chat bot102(2). The prompt can indicate a request for confirmation of the authentication process (i.e., of authenticating the chat bot102(2)) via the chat session106(2). Example of the prompt for authentication is shows at chat text330.

In some embodiments, the bot application104can determine what type of authentication credentials to provide. The authentication credential type selection can be based on a variety of criteria, including on a type of chat sessions being used and/or whether the user device is a mobile device (which can be determined based on the chat texts accessed in the chat session106(1) and/or106(2)). For example, the bot application104can determine that for the chat session108(1), a link for authentication is provided. The bot application104can determine that the one-time token can be provided only if the user device is a mobile device.

In some embodiments, the bot application104can determine which chat bot to use for providing the authentication credentials of210(and also for receiving the response of212). For example, if a third chat bot is also authenticated to access the user account at the transaction server116, the bot application104can determine whether to select the chat bot102(1) or to use the third chat bot for providing of the authentication credentials. The chat bot selection can be based on a variety of criteria, including whether the user device114is a mobile device (which can be determined based on the chat texts accessed in the chat session106(1) and/or106(2)). For example, the third chat bot is used when communicating with mobile devices. The chat bot selection can be based on security aspects of the chat session106(1) versus a third chat session used by the third chat bot, where the chat session106(1) is determined to provide better security. The chat bot selection can also be affected by the type of authentication credentials being used. In one embodiment, the bot application104can determine that multiple chat bots need to be used to authenticate the second chat bot. For example, the bot application can provide the authentication credentials via the chat bot102(1), but the response at212is received via the third chat bot.

At212, the bot application determines whether it has received a response referencing the authentication credentials. With reference toFIG. 1, the bot application104can access, via the chat bot102(2), chat text(s) at the chat session106(2) to determine whether a response has been provided that references the authentication credentials. Depending on the type of the authentication credentials, the response will vary. The response can be the one-time token that was initially provided at the chat session106(1). The response can be authentication received from a web page linked by the link. The response can be a confirmation of the authentication process that was referenced by at the chat session106(1). Depending on the response, the bot application104can determine whether the first chat application instance and the second chat application instance are both hosted by the same user device.

At214, the bot application authenticates the second chat bot, with the server, for the second session communication. With reference toFIG. 1, the transaction server116can authenticate the chat bot102(2) for communication with the chat application instance112(1) that accesses the user account. In some embodiments, at214the bot application104can move a transaction session from the first session communication to the second session communication. The transaction session can be for a transaction between the user account at the transaction server116and an account associated with another server. For example, the bot application can move the transaction session from the chat session106(1) to the chat session106(2).

FIG. 3illustrates embodiments of communication, via chat sessions, for authentication of the additional chat bot. Chat text300illustrates a chat text that can be provided, by the chat application instance112(1), to the chat session106. The chat text300can be accessed, via the chat bot102(1), from the chat session106. The chat text300includes chat text portions (also referred to as “portions”)302-308. The bot application104can access, via the chat bot102(1), the chat text300and parse the various portions302-306, such as to determine whether the chat text300indicates authentication intent. The portion302of “user:” indicates that the chat application instance112(1) is transmitting the chat text300. The portion of “Bot”304indicates that the chat text300is addressed to the chat bot102(1). The portion306of “I would like to authenticate with SLACK bot” indicates authentication intent by the user of the chat application instance112for authenticating the chat bot102(2).

The chat text310can include portions312-319. As indicated by312, the bot application104(1) can transmit, via the chat bot102(1) (named “PayPal Bot 1” in this example), the chat text310to the chat session106(1). The chat text310includes examples of authentication credentials. In the depicted example, the portion314of “user” indicates that chat text310is addressed to the user. The portion of316indicates that the token is presented at318. However, the portions318and319are provided as an example only, and may vary based on a type of authentication credentials being provided at the chat text310. For example, the portion of319is a link that can be provided instead of the token at318.

The chat text320can include portions322-328. The chat text320is provided via the chat session106(2). The portion322of “user:” indicates that the chat application instance112(2) is transmitting the chat text320(as it is addressed to the chat bot102(2) as indicated by324). The chat text326indicates that the token is provided at328. The chat text320is an example of a response that references the authentication credentials. In other embodiments, a different response can be provided using the chat text320or via other methods, such as by confirmation of the authentication and/or by accessing a link.

The chat text330can include portions332-336. As indicated by332, the bot application104can transmit, via the chat bot102(2), the chat text330to the chat session106(2). The portion of336is a prompt for the user (as indicated by334) to confirm the authentication of the chat bot102(2). It is noted that in some embodiments, the chat text330can instead be transmitted to the chat session106(1) by the chat bot102(1). The chat text330is a prompt for the response that references the authentication credentials.

FIG. 4is a timing diagram illustrating one embodiment of authentication of the additional chat bot at the additional chat session. As shown byFIG. 4, the chat application instance112(1) and the chat bot102(1) communicate with each other using a chat session106(1).FIG. 4indicates that the chat bot102(1) is already authenticated with the transaction server.FIG. 4indicates that the chat bot102(2) is new, meaning that it is not yet authenticated with the transaction server. The communications ofFIG. 4can be performed over one or more communication networks. Portions of the timing diagram ofFIG. 4can correspond to the flow diagram ofFIG. 2and/or to the communication shown inFIG. 3. It is noted that not all of the communication between the chat bots and the chat application instances are shown. Furthermore, some of the communication shown is optional.

At402, the chat application instance112(2) can provide a chat text at the chat session106(2). At404, the chat bot102(2) can access the chat text (provided at402) at the chat session106(2). At408, the authentication server (e.g., the transaction server116) can determine an intent to authenticate the chat bot102(2), based on the chat text accessed at404. At410, the chat bot102(2) can provide a chat text to the chat session106(2) requesting an indication of whether the user is using another chat bot that is authenticated for accessing the user account. Since the transaction chat bot102(2) is not yet authenticated, the transaction server may not have a record (e.g., a data entry in a database) indicating whether the user can access the user account using another chat bot (e.g., such as the chat bot102(1)).

At412, the chat application instance112(2) can provide a chat text, to the chat session106(2), indicating that the user uses the chat bot102(1) for authenticated access to the user's account at the transaction server. In some embodiments, the chat text at412is provided automatically, e.g., by the chat application instance112(2) in response to the chat text at410. At413, the chat bot102(2) can access the chat text indicating the authenticated chat bot102(1). At414, the transaction server can determine (e.g., by accessing the database) that the authentication intent is to authenticate the chat bot102(2) for the same user account that the chat bot102(1) is already authenticated. In some embodiments, each of the chat bots102(1) and102(2) is an instance of a chat bot, and each chat bot instance is communicating via only one chat session at a time. It is noted that the one or more of the communication402-413are optional.

At416, the chat application instance112(1) can provide a chat text at the chat session106(1). The chat text at416can indicate intent to authenticate the chat bot102(2). At418, the chat bot102(1) can access the chat text (provided at416) at the chat session106(1). At420, the chat bot102(1) can determine an intent to authenticate the chat bot102(2), based on the chat text accessed at418. At421, the chat bot102(1) can provide authentication credentials, for authenticating the chat bot102(2), at the chat session106(1). At422, the chat application instance112(1) can access the authentication credentials from the chat session106(1). At424, the chat application instance112(2) can provide a response, to the chat session106(2), that references the authentication credentials. The response can be accessed at426by the chat bot102(2). At428, the transaction server can authenticate, based on the response, the chat bot102(2). At432, the chat bot102(2) can provide a confirmation of the authentication. At434, the confirmation can be accessed by the chat application instance112(2).

It should be understood thatFIGS. 1-4and the operations described herein are examples meant to aid in understanding embodiments and should not be used to limit embodiments or limit scope of the claims. Embodiments may perform additional operations, fewer operations, operations in a different order, operations in parallel, and some operations differently. For example, one or more elements, steps, or processes described with reference to the diagrams ofFIGS. 2-4may be omitted, described in a different sequence, or combined as desired or appropriate.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer program code may execute (e.g., as compiled into computer program instructions) entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

FIG. 5is a block diagram of an exemplary embodiment of an electronic device500including a communication interface508for network communications. The electronic device can embody functionality to implement embodiments described inFIGS. 1-4above. In some implementations, the electronic device500may be a laptop computer, a tablet computer, a mobile phone, a powerline communication device, a smart appliance (PDA), a server, and/or one or more another electronic systems. For example, a user device may be implemented using a mobile device, such as a mobile phone or a tablet computer. For example, a payment system may be implemented using one or more servers. The electronic device500can include a processor unit502(possibly including multiple processors, multiple cores, multiple nodes, and/or implementing multi-threading, etc.). The electronic device500can also include a memory unit506. The memory unit506may be system memory (e.g., one or more of cache, SRAM, DRAM, zero capacitor RAM, Twin Transistor RAM, eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM, etc.) or any one or more of the above already described possible realizations of machine-readable media.

The electronic device500can also include the bus510(e.g., PCI, ISA, PCI-Express, HyperTransport®, InfiniBand®, NuBus, AHB, AXI, etc.), and network interfaces504can include wire-based interfaces (e.g., an Ethernet interface, a powerline communication interface, etc.). The communication interface508can include at least one of a wireless network interface (e.g., a WLAN interface, a Bluetooth interface, a WiMAX interface, a ZigBee interface, a Wireless USB interface, etc.), In some implementations, the electronic device500may support multiple network interfaces—each of which is configured to couple the electronic device500to a different communication network.

The memory unit506can embody functionality to implement embodiments described inFIGS. 1-4above. In one embodiment, the memory unit506can include one or more of functionalities that facilitate communicating in chat sessions using chat bots for authentication of additional chat bots. Any one of these functionalities may be partially (or entirely) implemented in hardware and/or on the processor unit502. For example, some functionality may be implemented with an application specific integrated circuit, in logic implemented in the processor unit502, in a co-processor on a peripheral device or card, etc. Further, realizations may include fewer or additional components not illustrated inFIG. 5(e.g., video cards, audio cards, additional network interfaces, peripheral devices, etc.). The processor unit502, the memory unit506, the network interface504and the communication interface508are coupled to the bus510. Although illustrated as being coupled to the bus510, the memory unit506may be coupled to the processor unit502.

While the embodiments are described with reference to various implementations and exploitations, it will be understood that these embodiments are illustrative and that the scope of the present disclosure is not limited to them. In general, techniques for using chat bots as described herein may be implemented with facilities consistent with any hardware system or hardware systems. Many variations, modifications, additions, and improvements are possible.