Patent Application
20120317215
The present innovation relates generally to computer software and computer network applications. More specifically, it relates to configurations for generating and managing electronic records that facilitate transactional interactions between two or more parties.
A “transaction” may be defined as a communication pattern occurring in the conduct of business and personal affairs between parties. A beginning of a transaction may be defined as the point when an initiating party makes a request to one or more specifically identified counterparties. One or more of these counterparties may respond to the request, and the requesting party may evaluate the response and decide whether to accept or reject the response outright, or to issue a counter-response that suggests modifications to the response. A transaction may incorporate an unlimited number of modified responses and counter-responses. The transaction may terminate when the initiating party accepts or rejects the response, when the initiating party cancels the transaction, or when one or both parties withdraw from or abandon the transaction. Although some transactions, notably transactions in highly regulated financial markets, are standardized as to their structure and content, many transactions require that the parties adjust flexibly to the specific circumstances of the transacting parties and the particular transaction.
Present software-based systems for handling transactions can be classified in three broad categories: workflow or business process management systems, task management systems, and general-purpose communication tools. Systems in all three categories exhibit significant shortcomings with respect to transaction management because they are not designed to handle transactions with the structure described above.
Systems with workflow or business process management capabilities such as those available under the tradenames Documentum®, Microsoft SharePoint®, and Lotus Notes® are designed to perform a sequence of partially automated transactions using predefined templates. When a given workflow has been triggered, such a system initiates a sequence of predefined transactions with a set of pre-assigned counterparties. The system acts as the initiating party, issuing requests and processing responses. The structure, content and sequencing of the transactions is determined by a set of predefined rules. Although this approach may work well for handling certain high-frequency, low-variability transactions, it is poorly suited to relatively less frequent, higher-variability transactions for two reasons.
First, creating a workflow pattern for the software to follow requires a significant investment of time, effort, and technical expertise, because the associated transactions must be classified, standardized, captured in a set of templates, and rules must be developed to determine how the transactions are carried out under any particular circumstances. For many transactions that occur in the course of business and personal affairs, these investments are not cost-effective, generally ruling out the use of workflow or business process management tools.
Second, as stated above, many transactions that occur in the course of business and personal affairs cannot be fully standardized, because they involve adjustment by the parties to particular circumstances at hand. These adjustments are often handled through counter-responses and modified requests that follow the initial request-response interaction. Since workflow and business process management tools automate the initiation and handling of transactions using predefined templates and rules, they are not well-suited to adjust flexibly to particular circumstances. Transactions that do not fit the templates and rules in the system must be handled outside the system, or the system must be modified.
As a result of these limitations, use of workflow or business process management systems is generally limited to transactions that are relatively frequent and that exhibit relatively low variability. Also, these systems are often used in conjunction with more flexible communication tools that can be used to handle transactions that cannot be easily standardized. For example, a workflow system may be used to collect formal approvals in a business environment after a decision has been made, but transactions associated with the actual decision-making process may be handled outside the system.
Task management systems allow users to create tasks and assign them to other people. In some cases, such a system may notify the task creator when the assignee has completed the task. Characterized in transactional terms, these systems allow a request to be issued in the form of a task, and for a response to be provided in the form of a notification that the task has been completed. However, as described above, issuing a request and receiving a response does not necessarily complete a transaction. Much of the difficulty in managing transactions is associated with the need to handle a series of counter-responses and modified requests.
Since task management systems are not designed to handle the entire sequence of transactional interactions, they generally are suitable for only very simple transactions, or for initiating and tracking the completion of transactions that are conducted using other communication tools. For example, when an assignee receives a task, the assignee might use a series of emails or telephone calls with the task creator to perform the transaction, and then mark the task complete in the task management system.
The clearest evidence of the limitations of existing workflow/business process management and task management systems is the very large volume of transactions that are conducted using the third category of transaction-handling system: email, telephone, and other general-purpose communication tools. These tools permit the transmission of messages among the parties to a transaction, but they generally do not have any transaction management functionality. Specifically, these systems typically do not track when a transaction has been initiated, whether a response has been received from the counterparty, how the content of the response maps to the structure of the request, what counter-responses or modified responses have been issued, or whether the transaction has completed and, if so, with what outcome.
As a result, general-purpose communication tools are an inferior technology for handling transactions. It generally is not possible to track or monitor ongoing transactions or analyze completed transactions, and managers in an organization generally cannot identify problematic transactions or evaluate transaction-processing performance by individuals or groups. Further, it generally is not possible to aggregate similar transactions for monitoring or analytical purposes, or to store the structure of completed transactions for reuse in the future, so transactions are recreated from scratch every time, requiring extra effort.
These limitations have significant practical implications, especially for organizations such as businesses. When general-purpose communication tools are used to handle transactions, it is difficult or impossible for managers to obtain, at a reasonable cost and in a timely fashion, information about much of the transactional activity that is occurring or has occurred within the organization. This impedes the detection of problems, hinders the objective and accurate evaluation of staff performance, and reduces the ability of managers to make timely and well-informed business decisions.
None of these existing systems can be easily modified to effectively overcome their limitations with respect to transaction handling. Workflow and business process management tools are designed to automate business processes by automatically initiating sequences of transactions and processing responses, so they are not structured to facilitate ad hoc transactions between human actors. General purpose communication tools do not have the necessary structure to enable transaction management functionality; Google's Gmail® and other email clients can group related messages by subject which may help somewhat, but there is no way to determine the status of a transaction reliably from the information in an email message. Finally, task management systems are designed to enable assigning tasks and tracking whether tasks have been completed, so they cannot accommodate a sequence of interlocking, structured interactions that may be of arbitrary length and complexity.
What is presented is a worldwide web based, or cloud-based, solution for modeling electronic communication transactions, or communication “handshakes”, comprising a web service, client applications, and additional interface components integrated with other end user applications such as email, calendar, contact manager, social media, or other enterprise IT. The solution may also be deployed using private cloud and on-premises configurations.
The client applications may be configured to enable users to access the web service and perform the various activities. Clients may comprise HTML websites, javascript applications running in a web browser, applications for personal computers running operating systems such as Microsoft Windows® or Mac OS®, or apps for mobile devices running operating systems such as Apple iOS® or Google Android®.
One embodiment is directed to a system for structured communication between specified parties, comprising a remotely-accessible controller configured to present a communication user interface to one or more of the parties; and a state information repository comprising state information to be updated throughout a transaction, wherein changes in the state information are constrained at least in part based upon a transaction type determined from a predetermined set of transaction types; wherein the controller is configured to initiate an electronically mediated interaction pertinent to a communication transaction between the parties, attempt to establish an initial context for the transaction based upon previous electronically-mediated interactions that include the initiating party, establish a defined role for each of the parties, each role defining bounds upon the activity of each party within the transaction, and, upon advancement of the state information from a first state to a second state, engage associated parties through the user interface. The system further may comprise one or more computing platforms through which the communication interface is presented to the one or more parties. The one or more computing platforms may be configured to operate a web browser to operate the communication interface. At least one of the one or more computing platforms may be selected from the group consisting of: a mobile phone, a PDA, tablet computer, a laptop computer, and a desktop computer. The controller may be configured to initiate an electronically mediated interaction pertinent to a communication transaction between the parties by sending an email. The controller may be configured to initiate an electronically mediated interaction pertinent to a communication transaction between the parties by operating an application configured to function as a plug-in to an email client. The email client may be based upon an application platform selected from the group consisting of: local computer application, online application, and a mobile application. The controller may be configured to initiate an electronically mediated interaction pertinent to a communication transaction between the parties by connecting directly with an email server. The controller may be configured to initiate an electronically mediated interaction by detecting events from an electronic calendaring system. The controller may be configured to initiate an electronically mediated interaction pertinent to a communication transaction between the parties by selecting a previously-existing transaction. The predetermined transaction types may include one or more transaction types that are based at least in part upon previously initiated transactions. The controller may be configured to initiate an electronically mediated interaction pertinent to a communication transaction between the parties by establishing dates that trigger actions by the controller. The controller may be configured to attempt to establish an initial context for the transaction by detecting transactions currently selected by the initiating party/originator in the user interface. The controller may be configured to attempt to establish an initial context for the transaction by detecting transactions currently visible to the initiating party through the user interface. The controller may be configured to attempt to establish an initial context for the transaction by detecting transaction elements currently selected by the initiating party in the user interface. The predetermined set of transaction types may be selected based at least in part upon the initial context. The transaction type may be determined at least in part based upon the initial context. The predetermined transaction types may comprise a transaction type that may be acknowledged but does not require acknowledgement. The predetermined transaction types may comprise a transaction type that requires an acknowledgement. The predetermined transaction types may comprise a transaction type that requests a response. The predetermined transaction types may comprise a transaction type that requests approval of specified items. The predetermined transaction types may comprise a transaction type that modifies the set of parties to the transaction. The predetermined transaction types may comprise a transaction type that modifies the roles of parties to the transaction. The predetermined transaction types may comprise a transaction type that requests parties to the transaction to propose meeting times. The predetermined transaction types may comprise a transaction type that requests parties to the transaction to approve proposed meeting times. The controller may be configured to initiate an electronically mediated interaction pertinent to a communication transaction between the parties by receiving triggering information from a calendar system. The predetermined transaction types may comprise a transaction type configured such that a first party introduces a second party and a third party to each other. The controller may be configured to establish a defined role by presenting information to the party in a manner contingent upon the defined role. The controller may be configured to establish a defined role by receiving information from the party in a manner contingent upon the defined role. The controller may be configured to establish a defined role by limiting the actions available to each party through the user interface. The state information may comprise a state selected from the group consisting of: a sent state, a viewed state, a waiting-for-response state, a waiting-for-acknowledgement state, a cancelled state, and an abandoned state. The controller may be configured to monitor a time elapsed after a response was requested, and to issue a reminder to one or more parties to the transaction. The controller may be configured to allow parties to the transaction to associate information with the transaction. The controller may be configured to track time associated with changes to the transaction state. The controller may be configured to establish relationships between two or more parties. The controller may be configured to characterize membership of a particular party in one or more groups. The controller may be further configured to establish a set of tags. The controller may be further configured to specify a delegate for one or more of the parties. The controller may be further configured to modify the parties to a transaction under a specified circumstance. The controller may be further configured to request information from a party to a transaction after the transaction reaches a terminal state. The controller may be further configured to specify at least one of the one or more parties from a group of predetermined candidates. The controller may be configured to display summary information regarding the communication transaction through a graphical user interface. The controller may be further configured to display information to a user generated at least in part upon one or more transactions to which the user was not a party. The controller may be further configured to automatically suggest values for one or more input fields in a current transaction.
FIGS. 4A to 4Z-13 illustrate various aspects of an exemplary paradigm wherein several members of a law firm are working together to address tasks and communication transactions using various aspects of the inventive systems and methods.
Referring to
Referring to
Referring to
Given such infrastructure, other elements may also be added. For example, referring again to
Referring to
To further illustrate such attributes of various embodiments of the inventive application, aspects of a typical business scenario are featured in FIGS. 4A to 4Z-13 as addressed with embodiments of the application. In this hypothetical but realistic scenario, a law firm is contacted and asked to represent one company in a possible acquisition of another company. The related seemingly simple set of communications is actually relatively complex, and with a conventional communications platform such as an email service, many emails will be generated in many inboxes of users, with little tracking of tasks and order that are necessary for the efficiency of the process and individuals involved therein.
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
In one embodiment, attempting to establish an initial context for the transaction based upon electronically-mediated interactions to which the initiating party has access may involve scenarios such as one wherein a supervisor initiates a follow-on transaction to be pursued by one or more members of his team.
As briefly noted above, the subject electronic communication transactions may also be denoted as electronic “handshakes”—which, again, represent stateful, goal-oriented interactions such as questions, requests, or notifications requiring acknowledgement. Existing technologies for performing handshakes, including email and telephone, do not capture the structure of the interaction, so tracking and managing handshakes is left to individual workers. Workers waste large amounts of time monitoring and prioritizing pending handshakes, retrieving information about handshakes, and recreating repetitive handshakes. The subject configurations address these challenges with a cloud-based communication platform that organizes worker interactions into discrete handshakes with explicit structure and state. Rather than requiring workers to define interaction structure beforehand, the technology may be configured to allow interactions to unfold naturally and to work in the background to capture structure and state information as it emerges. The technology may be configured to use this information to provide fine-grained insight into how and by whom work is getting done, and where attention is required. The technology may be configured to automatically organize handshake information and provide a shared, consistent view to all participants, helping workers see the big picture and avoid information overload. Handshakes may be reused, increasing efficiency and facilitating standardization. In contrast to other structured communication tools, the subject technology may be configured to capture the microstructure of individual interactions as they occur and aggregate upward to provide high-level visibility and manageability. This contrasts with traditional process management tools such as those available under the tradenames Documentum® or Microsoft SharePoint®, which require detailed process definitions upfront, a costly and time-consuming exercise. The approach of the subject technology also differs from task and project management tools such as those available under the tradenames Microsoft Project®, Basecamp®, or Asana®, which provide a framework for defining the work to be done and reporting when tasks have been completed, but do not capture the interactions through which the work actually takes place. Since communication occurs outside of task and project management tools, these tools cannot help workers track and manage individual handshakes. By capturing handshake structure and content, the subject technology may be configured to deliver the transparency, manageability, and reusability associated with process automation while leaving workers in control and minimizing upfront costs. It may be configured to interoperate with and complement email, minimizing disruption to existing communication patterns. It may be configured to provide basic functionality free of charge to encourage a spread of the technology virally as workers interact with colleagues already using the platform. Additional functionality for managing handshakes across organizational units may be sold to organizations where workers have already adopted certain aspects of the subject technology. Handshakes are a central part of information work. For example, common handshakes include questions; notifications, confirmations, reminders, or handoffs requiring acknowledgement; and requests for comments, meetings, approvals, or decisions. The cost and inflexibility of traditional process automation technologies have limited their application, so many handshakes take place over email or telephone instead of within process management systems. Unfortunately, email and telephone are designed for transmitting one-off messages, not for managing complex interactions from start to finish, so information workers must track and manage large numbers of handshakes manually. The subject technology may be configured to automate handshake tracking and management, saving valuable time and enabling high quality decisions by giving workers and supervisors greater insight into their collaborative work; it may be configured to provide a platform for creating flexible handshakes that expand hierarchically to handle complex interactions between multiple workers. Handshakes capture structured information about an interaction including the roles of the participants (e.g., initiator, responder, observer), the state of the interaction (waiting for a response from a specific participant, overdue, complete, canceled, etc.), related information associated with the interaction (attached files, forms, links, etc.), and subsidiary interactions that must be completed first. By allowing the creation of subsidiary handshakes, the handshake enables emergent organization of arbitrary complexity. Encapsulating all communication within structured handshakes enables automated tracking and aggregation, as well as facilitating reuse of handshakes that occur frequently. Other social media platforms provide structured communication tools for sharing information with friends (Facebook®), sharing professional information with colleagues (LinkedIn®), and assigning clearly-defined tasks to collaborators (Asana®), but no extant technologies provide a platform for creating and managing flexible handshakes of unlimited complexity. To a substantial degree, organizational activity consists of communication patterns that can be modeled naturally and flexibly as hierarchically nested clusters of goal-oriented handshakes. For example, one worker may notify a second worker that a new piece of equipment is needed. The second worker may ask a third to investigate possible vendors for the equipment. The third may ask some clarifying questions of the second before providing the requested information. Then the second worker may ask for comments and/or approval from several other workers before asking yet another worker to purchase the selected equipment. Using email or other conventional project or task management technologies, it is very difficult for a user to maintain a picture of these handshakes as they unfold that is current, concise, and comprehensive. A technology that captures handshakes in the background, without requiring up-front specification of the process or even the specific tasks to be done, such as the subject technology, can provide visibility and manageability without impeding the ability of information workers to get things done through ad hoc communication with coworkers.
The subject technology can be configured to increase the productivity of information workers by streamlining handshake management and facilitating complex interactions. At the same time, the technology can generate detailed data about the content of information work that will enable new technologies and management techniques. For example, managers can utilize the subject technology to visualize and monitor white collar work in real time, evaluate employee performance objectively, spot problems and bottlenecks quickly, and, when necessary, drill down into the details of specific transactions or decisions. By analyzing patterns in handshake data, associated artificial intelligence systems or subsystems may be configured to make suggestions about whom to involve in a decision or what information might be relevant to a question. Such systems may be configured to detect unusual or unexpected activity patterns and report them to workers and managers. If the past few decades are any guide, more effective integration of humans and computers should yield organizations that are more productive and intelligent.
In accordance with aspects of the present invention, an object-oriented database or databases may be used instead of an SQL database or databases to simplify the architecture and increase flexibility. Handshake clusters may be reused in a way that preserves a handshake structure but also maintains flexibility. Worker relationships with other workers and with organizations may be modeled in a manner that enables fine-grained security controls and management of information sharing. An intuitive user interface may be presented to users and utilized to require a minimum of training, and places as little burden on the user as possible, where user interface burden is measured in terms of the amount of information visible and the number of options available at any given point, and the number of interactions required to perform a given action or access given information. Integration configurations may enable interoperation with as little user interface overhead as possible. The system may comprise a highly scalable and evolvable backend architecture based upon information assembly line principles that can handle large numbers of handshakes and users.
The system may comprise (1) a service accessible over a computer network such as the Internet or a corporate intranet, (2) client applications that enable users to interact with the service, and (3) additional interface components that integrate the service with other applications such as email clients, calendars, contact managers, corporate identity servers, enterprise IT systems, and other social media. The service preferably enables users to perform a variety of activities relevant to the initiation and management of handshakes. These functions include user account management, handshake management, coworker relationship management, organization management, and app management. The service may comprise a gateway service that accepts requests from client applications and a cluster of backend services that handle the functions identified above. The Gateway Service may be configured to accept requests from client applications in the form of structured forms encoded electronically using a standard protocol such as JSON. Client applications may communicate with the Gateway Service over a computer network such as the public Internet or a private intranet. The Gateway Service may be implemented as a Django or Pylons application that integrates with a standard web server using the Web Server Gateway Interface.
When the Gateway Service receives a request, it may be configured to create a hierarchical data structure called a “pallet” that is used to encapsulate the request, the (as-yet-incomplete) response to the client application, and routing information that specifies the sequence of services to which the pallet will be routed in order to complete the response. Then, the Gateway Service may be configured to route the pallet to the backend services according to the routing information. Routing to backend services may be serial or parallel depending on the structure of interdependencies among the backend services and latency concerns.
The backend services may be configured to receive pallets from the Gateway Service, modify the contents of the pallets as appropriate, and return the pallets to the Gateway Service for further processing. The backend services may be implemented as servers using a language such as Python and a protocol such as XML-RPC. Pallets may be transmitted to and from the backend servers using a standard encoding such as JSON or XML. The core backend services may be as follows.
A Roles Services module may be configured to handle user account management: registration of new people and roles, and the maintenance of people and roles databases. The databases may be object databases using a technology such as ZODB or standard SQL databases. The Roles Service also may be configured to handle authentication of users who attempt to access the service by checking credentials against those stored in databases and issuing challenges when appropriate. In one embodiment, organizations can, through the Organizations Service (see below) configure the Roles Service to use a corporate identity service such as Open Directory or LDAP for authentication of users attempting to access the service as an agent of the organization.
People may interact with the system in multiple roles (e.g., in a personal capacity and as an employee of an organization), so the system supports multiple roles for each person. Permissions and privileges may be managed for both people and roles. The Roles Service also may be configured to handle modification of account information and account termination. The Roles Service may be configured to maintain indices of the handshakes, apps, coworker relationships, and organization memberships associated with each role.
A Handshake Service may be configured to handle the creation of new handshakes and retrieval or modification of existing handshakes. The service may be configured to support retrieval of single handshakes or groups of handshakes based on some selection criteria (e.g., all handshakes having a given person as a participant or including a given keyword). Handshakes may be retrieved in the form of compact summaries (header form) or retrieved in full. Handshakes may be retrieved together with all child handshakes in full or in header form.
Handshakes may be modeled as data structures that include information about the participants, state, related information and related handshakes. More detailed information about each component of the handshake data structure follows below.
As described above, a handshake may be a structured interaction between two or more participants, who may or may not be registered users. These participants may participate in the handshake in a role (e.g., as an agent of an organization). Participants also have one or more roles relative to the handshake (handshake roles) such as owner, administrator, handler, initiator, observer, or responder. The system may be configured such that permissions of a participant with respect to a handshake may depend on the role of the participant with respect to the handshake. The Handshake Service may be configured to support the additional and removal of participants.
Retrieval and modification of handshakes may be restricted by the service based on the role of the user. The system may be configured such that a person who is the owner or administer of a handshake, or the supervisor of such a person, can retrieve and modify the handshake without limit. Other handshake roles may have more limited privileges.
The system may be configured such that a handshake models a finite state machine that progresses from an initial state to one of two terminal states (complete or canceled). States may model whether the handshake has been viewed, whether a response is required, whether a response has been received, etc. Additionally, a handshake may have a due date and may be overdue. The ownership of a handshake, which may be assigned to a participant or to an organization, may also considered to be part of the handshake's state.
The handshake also may have a type, which may be a generic handshake of one of several built-in types, or it may be a custom type that may be handled by another service with an appropriate API. The service may be configured to keep track of custom types and services used to handle them.
The Handshake Service may be configured to support modification of state parameters such as the due date, and update handshake state as appropriate when a handshake changes (e.g., when a client informs the service that a handshake has been viewed).
Handshakes may include two collections of related information: a log recording actions taken by participants (the Feed) and a hierarchical data structure (the Binder) containing information (links, files, forms, etc.) that participants have added to the handshake.
The Handshake Service may be configured to update the Feed as necessary when users take actions relative to a handshake (e.g., send a message, post information or initiate or modify a child handshake). Certain kinds of child handshakes may provide summaries for inclusion in the Feed, such as questions, FYIs, and pings. The Handshake Service also may update the Binder when users add information or initiate or modify child handshakes that provide summaries for inclusion in the Binder. Users may organize information in the binder by creating sections (which can be nested without limit) and moving information into these sections.
The system may be configured such that a handshake can be initiated within the context of another handshake, creating a parent-child relationship where the new handshake is a child. The child handshake may affect the parent handshake, e.g., by adding participants, changing the due date, or adding content to the Feed or the Binder.
Child handshakes may be represented in the handshake data structure by including references to the handshakes that are the parent or the children of the handshake. When retrieving a handshake, the Handshake Manager may be configured to examine the handshake's child handshakes and incorporate information about these child handshakes as appropriate in the Feed and the Binder.
Several types of handshakes may be defined by the Handshake Manager, and APIs may be configured to allow for definition and custom handling of other handshake types. The system may be configured such that handshake types defined by the Handshake Manager include:
Generic Handshake: A handshake that consists of an unstructured message requiring an unstructured response.
Meeting Request: Schedule a meeting about the parent handshake, inviting participant(s) in the parent handshake and, optionally, other people, where the response to the handshake is a comment, RSVP, or request to reschedule.
Meeting Notes: Record notes about the items covered at a meeting, where the response is a request to modify the notes or approval of the notes. The system may automatically prompt the initiator of a meeting request handshake to initiate a Meeting Notes handshake after the meeting's scheduled completion time.
Collect structured information: collect information using a customizable, hierarchically structured form, from participants in the parent handshake or other people.
FYI: Enter a message that allows other participants to acknowledge receipt of the message and display a list of participants who have acknowledged receipt.
Ping: Enter a message that calls attention of participants to an existing handshake or an element (information or child handshake) within it and require acknowledgement of receipt, and display a list of participants who have not yet acknowledged receipt.
Approval Request: Send a message, in one embodiment referring to a child handshake or other element, asking for explicit approval, which requires responder(s) to answer yes, no, or request changes, and displays the result.
Comment Request: Ask for comments, in one embodiment referring to a child handshake or other element.
Selection Request: Ask for a selection from multiple choices and include the results in the handshake.
Question: Ask question about handshake or elements in it and associate answer with handshake
Handoff: Transfer one's own role in handshake to another person fully or leaving self as an observer, temporarily or permanently (handoff)
The system may be configured to allow users to establish relationships with coworkers in order to streamline the initiation and management of handshakes with them. A Coworkers Service may be configured to handle creation of new relationships, retrieval of relationships, and modification or deletion of relationships. A relationship may be modeled as a data structure that stores the two parties to the relationship, the roles, if any, in which they are engaging in the relationship, and meta data about the relationship such as its creation date, the type of relationship (e.g., coworker, client, supervisor-subordinate) and its context (e.g., the organization where the people are coworkers).
The system may be configured such that initiating a relationship requires that one person request the relationship with a second person and that the second person approve the relationship. This may be handled as a handshake using APIs exposed by the Handshake Service for creating, representing, and modifying handshakes.
An Organizations Service may allow representatives of organizations to register the organization, specify which users are members of the organization, and define the roles of these people with respect to the organization. Subsequently, organization membership may be used to determine permissions and privileges of users with respect to handshakes associated with the organization. Organizations may be modeled as data structures that include information about the organization's registration with the service, its representatives, and the set of organization members.
The system may be configured such that the Organizations Service handles registration of organizations and modification of account information. In some cases, modifications may be handshakes requiring approval by other organization representatives; these may be handled using custom handshake types through the Handshakes Service APIs.
The Organizations Service also may allow the registration of sub-organizations such as divisions, business units, committees, or teams within other organizations. This may be modeled using parent-child references in the organization records. An existing organization may become a child of an existing organization through a custom handshake between representatives of the two organizations.
An Apps Service may be configured to handle Apps (applications) that allow users to create handshakes of specified types. An App may be internal or external. Internal Apps may comprise a data structure containing a template defining the structure of the handshakes created from the app and meta data defining who can use the app, characteristics of handshakes created by the app such as service level guarantees, and information (or references to information) about past use of the app including feedback on the performance of the app from users. The app may also specify the ownership of handshakes that it creates, participants in the handshake, and constraints on transfers or ownership or addition of participants (e.g., only participants belonging to a specified organization can be added to the handshake.
External apps may comprise a data structure similar to the data structure for an internal handshake except that, instead of a handshake template, the data structure may specify the interface to a service that will provide, on demand, a handshake data structure. The Apps Service may implement APIs that allow providers of external apps to access and modify, subject to constraints, the meta data associated with the app.
The system may be configured such that client applications (clients) enable users to access the Service and perform the activities handled by the various system components described above. Clients may include HTML-based web sites, JavaScript applications that run in a web browser, applications for personal computers running operating systems such as Microsoft Windows® or Mac OS®, or apps for mobile devices running operating systems such as iOS or Android. A client may enable a person to log in and modify account settings; initiate, view and manipulate handshakes; form coworker relationships and view information about coworkers; establish and modify organization memberships; and create or configure apps.
The client may be configured to issue requests to the service using a protocol such as HTML. The requests may be structured as forms encoded using a standard such as JSON and containing the information necessary to handle the request.
In order to make the initiation and management of handshakes as efficient as possible, the system may comprise interface components that connect the system to individual and enterprise applications.
Interface components that connect the system to individual applications may include email connectors, calendar connectors, address book connectors, and cloud-based document connectors.
The system may be configured such that email connectors allow users to initiate handshakes or child handshakes from incoming or outgoing email messages or associate incoming or outgoing email messages with existing transactions.
An email connector may be a server-side component that receives emails copied to an address specific to the user and creates a new handshake with the email body in the feed, attachments to the message (if any) in the binder, and the sender and recipients as the handshake participants.
A more sophisticated email connector may comprise a component that plugs in to an email client (an email plug-in). The email plug-in may allow a user to select an incoming or outgoing email message and turn it into a handshake. The plug-in may allow the user to select the type of handshake to create (e.g., a Question, Meeting request, or Ping) and to enter additional information associated with the handshake such as target completion date, other participants, or parameters specific to the handshake type (e.g., possible meeting times or a specific question). The plug-in may allow a user to create handshakes from recently sent messages.
The plug-in also may allow a user to initiate the handshake as a child of an existing handshake or simply associate the message with an existing handshake as a piece of relevant information.
The service may comprise a server-side component that inserts meetings scheduled using a meeting request handshake into a user's calendar. A plug-in for a calendar application may also be included that allows users to view information about a handshake (and its child handshakes) associated with a meeting or to associate a calendar appointment with a meeting.
The service may comprise a server-side component that imports data from a users contact manager or a corporate directory server in order to identify possible coworkers or transaction participants.
The service may comprise one or more server-side components that enable posting into handshake documents stored in the cloud in services with externally accessible APIs. If these APIs permit accessing metadata about or content of the documents, the components may generate summaries describing the documents and provide them to the Handshakes Manager for incorporation into the Binder.
One target market for the subject technology is the information worker who currently uses email intensively for handshakes with coworkers, and the companies that employ these workers. One customer may be a professional who collaborates with several groups of coworkers on a number of projects at any given time. Examples include lawyers, consultants, investment bankers, project managers, mid-level executives, and financial advisors. The continuing trend toward project-oriented organizations means that traditional white-color jobs increasingly fit one or more customer profiles.
These workers often struggle with several serious problems arising from the limitations of traditional communication tools:
Fragmented communication. In a conventional paradigm, information regarding a given interaction may be spread across multiple messages in email accounts belonging to different people, attachments, shared files, etc. There may be nowhere to go for a comprehensive record of the interaction. This decreases the quality of decision-making, which depends on access to current, complete, well-organized information.
Lack of visibility. With conventional technologies, workers generally cannot see the state of pending interactions with coworkers, or of related interactions between coworkers and other people. As a result, workers generally must try to keep track of pending interactions themselves using task lists or email flags, and then send follow-up messages or schedule meetings to receive updates on the state of pending interactions. Managers may struggle to monitor process performance, detect bottlenecks, and evaluate workers objectively.
Time wasted onboarding coworkers. With conventional tools, when a coworker is brought into an existing interaction, he or she must be provided with the relevant context: background information, other participants, related activities and pending interactions, etc. This often requires time-consuming meetings and considerable effort on the part of the new coworker.
Inability to store and reuse interaction patterns. In a conventional paradigm, although worker interactions are highly varied, there tend to be patterns. Using email or telephone, however, these patterns are difficult to capture and reuse. Thus, workers end up wasting time reinventing the wheel, or searching for and copying and pasting from old emails.
In one embodiment, centralized management functionalities may comprise:
automated management of organization membership, roles, and access to self-service modules
automated maintenance of aspects of organizational control over handshakes, interaction templates, and data
automated summarizing of activity by group or process, with configurations facilitating drill down to specific handshakes
capabilities for assignment of staff to handle handshakes originating from self-service modules
Referring to
In one embodiment, to support “offline” use (i.e., when connectivity to the remote server 138 has been interrupted), the application may be set up to have some caching in the browser (with HTML 5, “local data store” may be utilized). In another embodiment, a plug in for a mail client, such as Microsoft Outlook® may be installed locally on an operator's computing system to assist with seamless back and forth between such mail client and the subject web service configuration (i.e., in one embodiment, it is the intention to have the web service completely in sync with an email system such as Outlook, such that a request in the web service will be seen (or optionally not seen) as an email message in the mail client). As graphical user interface “sidebar” may be created with the mail client plug in to show the content of the interaction, links to jump to one or more related email messages, related calendar items, and the like.
In one embodiment, the data repository operatively coupled to the server (138) may comprise one or multiple databases configured to store different subsets of the information. For example, key recent interaction data may be stored in a more readily-available configuration than older data, wherein it may be perfectly acceptable to have higher latency in retrieval. The server and associated data repository may be located on the other side of a firewall from a corporate computing infrastructure, or may be within the firewall, such as in a “virtual machine” configuration that runs on any kind of server (Windows®, Linux®, etc) that encapsulates the entire corporate communication system behind the corporate firewall for security or other purposes.
Various exemplary embodiments of the invention are described herein. Reference is made to these examples in a non-limiting sense. They are provided to illustrate more broadly applicable aspects of the invention. Various changes may be made to the invention described and equivalents may be substituted without departing from the true spirit and scope of the invention. In addition, many modifications may be made to adapt a particular situation, material, composition of matter, process, process act(s) or step(s) to the objective(s), spirit or scope of the present invention. Further, as will be appreciated by those with skill in the art that each of the individual variations described and illustrated herein has discrete components and features which may be readily separated from or combined with the features of any of the other several embodiments without departing from the scope or spirit of the present inventions. All such modifications are intended to be within the scope of claims associated with this disclosure.
The invention includes methods that may be performed using the subject devices. The methods may comprise the act of providing such a suitable device. Such provision may be performed by the end user. In other words, the “providing” act merely requires the end user obtain, access, approach, position, set-up, activate, power-up or otherwise act to provide the requisite device in the subject method. Methods recited herein may be carried out in any order of the recited events which is logically possible, as well as in the recited order of events.
Exemplary aspects of the invention, together with details regarding material selection and manufacture have been set forth above. As for other details of the present invention, these may be appreciated in connection with the above-referenced patents and publications as well as generally known or appreciated by those with skill in the art. The same may hold true with respect to method-based aspects of the invention in terms of additional acts as commonly or logically employed.
In addition, though the invention has been described in reference to several examples optionally incorporating various features, the invention is not to be limited to that which is described or indicated as contemplated with respect to each variation of the invention. Various changes may be made to the invention described and equivalents (whether recited herein or not included for the sake of some brevity) may be substituted without departing from the true spirit and scope of the invention. In addition, where a range of values is provided, it is understood that every intervening value, between the upper and lower limit of that range and any other stated or intervening value in that stated range, is encompassed within the invention.
Also, it is contemplated that any optional feature of the inventive variations described may be set forth and claimed independently, or in combination with any one or more of the features described herein. Reference to a singular item, includes the possibility that there are plural of the same items present. More specifically, as used herein and in claims associated hereto, the singular forms “a,” “an,” “said,” and “the” include plural referents unless the specifically stated otherwise. In other words, use of the articles allow for “at least one” of the subject item in the description above as well as claims associated with this disclosure. It is further noted that such claims may be drafted to exclude any optional element. As such, this statement is intended to serve as antecedent basis for use of such exclusive terminology as “solely,” “only” and the like in connection with the recitation of claim elements, or use of a “negative” limitation.
Without the use of such exclusive terminology, the term “comprising” in claims associated with this disclosure shall allow for the inclusion of any additional element—irrespective of whether a given number of elements are enumerated in such claims, or the addition of a feature could be regarded as transforming the nature of an element set forth in such claims. Except as specifically defined herein, all technical and scientific terms used herein are to be given as broad a commonly understood meaning as possible while maintaining claim validity.
The breadth of the present invention is not to be limited to the examples provided and/or the subject specification, but rather only by the scope of claim language associated with this disclosure.
The present application claims the benefit under 35 U.S.C. §119 to U.S. provisional patent application Ser. No. 61/495,821, filed Jun. 10, 2011. The foregoing application is hereby incorporated by reference into the present application in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61495821 | Jun 2011 | US |
