Patent Application
20100293021
This application incorporates by reference in its entirety the information from the computer program listing appendix submitted herewith, comprising the files listed in the table below:
on the compact disc submitted herewith, and the computer program which is represented by their combination. Two identical discs, each containing the files listed above are submitted herewith.
There are a variety of technologies known in the prior art for tracking the completion of tasks. These range from personal information management systems such as Outlook, to project management systems such as MS Project and ERP systems that employ Gantt charts, milestones, and tasks and subtasks with complex dependencies.
One aspect shared by many prior art systems is that they define tasks to be completed by what will be required to complete them in the future. While this may be effective for tasks which are routine and where the future can be forecasted well, in contexts where the future is not known or cannot be accurately forecasted, they often break down. Additionally, prior art systems often lack administrative functions which can be useful in tracking work which is being done (and has been completed) on tasks.
The teachings of this disclosure can be used to implement systems which, among other things, address the weaknesses of the prior art approaches set forth above.
Disclosed herein are various tools and techniques which can be used in task tracking and allocation. For example, based on the disclosure set forth herein, one of ordinary skill in the art could create a computer readable medium having stored thereon a set of instructions operable to configure a computer such that the computer is operable to perform a set of tasks. That set of tasks might comprise maintaining a database, generating a first interface displaying subjects specifically associated with individual issues, generating a second interface displaying notes uniquely related to an issue selected by a user, sending notifications to users when a new note is created, begin incrementing a time record based on a signal generated by a user, and generating and outputting a report based on a set of report information specified through a report specification interface. The set of tasks might also include generating a search interface operable to allow a user to specify a set of search criteria, and the subjects displayed to the user in the first interface might be the subjects associated with the issues that match the search criteria.
The set of tasks might also comprise presenting a priority modification interface. In some implementations, there might be a list of subjects presented to a user in a manner that indicates the relative priorities of the issues associated with those subjects. A priority modification interface could allow a user to modify the priorities associated with specific issues, and the modified priority information could be stored in a database comprising the issues so that the change in priority would be reflected in future interfaces. Another task which instructions on a computer readable medium could configure a computer to perform is, in response to receiving a message comprising a text string, identifying the sender of the message by searching a plurality of stored user records to identify the user who sent the message, then starting to increment a time record for the user indicating work done by the user.
Also, in some instances, instructions stored on a computer readable medium and implemented according to this disclosure could configure a computer to maintain a database comprising a plurality of folders organized into a hierarchy. The database might also comprise a plurality of relationship records containing data indicating relationships which might stretch across folders. In such an implementation, the instructions might also be operable to configure the computer such that it was operable to present a relationship record interface which the user could use to examine a relationship record in one folder. Such interface might also, in response to a user indicating a cross-folder relationship with a second relationship record, display information related to that second relationship record.
Of course, the above description should be understood as being illustrative only. The disclosure herein could be used to create computer readable media having instructions stored thereon which could configured a computer to perform additional or different tasks than identified above. Additionally, the disclosure set forth herein is not limited to implementation in the form of computer readable media, and could similarly be used in implementing servers or performing various methods. Accordingly, neither the claims set forth herein or on any document claiming the benefit of this disclosure should be limited by the examples of computer readable media provided above.
The drawings and detailed description which follow are intended to be merely illustrative and are not intended to limit the scope of the invention as set forth in the appended claims.
a-2k depict interfaces which could be presented to a user by a system for task tracking and allocation.
a-3b depicts relationships between various conceptual entities which could be maintained in a system for task tracking and allocation.
The inventors have conceived of novel technology for task tracking and allocation. For the purpose of illustration, this disclosure is organized around certain exemplary embodiments and uses of task tracking and allocation technology. However, it should be understood that those of ordinary skill in the art will be able to implement technology for task tracking and allocation which diverges from the explicit disclosure in this application without undue experimentation in light of the teachings set forth herein. Therefore, the discussion herein should be understood as being illustrative only, and not limiting on the scope of claims which are set forth in this application, or which are included in future applications which claim the benefit of this application.
Turning now to the drawings,
As shown in
Also, as shown in
As referred to in the discussion of notes [302], some implementations of task tracking and allocation technology based on this disclosure might also maintain information about issues [303] (that is, a unit of work product which needs to be created, or a defined unit of work which needs to be performed). In some implementations, the information maintained about an issue might include information such as: a client on whose behalf work on the issue is performed; notes relevant to the issue; and a subject (i.e., descriptive text reflective of the general nature of an issue). Also, as depicted in
Additionally, it should be understood that the relationships shown in
In some implementations, in addition to (or as an alternative to) the entities depicted in
In practice, it is possible to implement the teachings of this document to create a system which can be used to perform tasks such as shown in
Initially, in the activities set forth in
One of the functionalities the user [101] could access from the main screen [106] is to search [107] for issues having certain characteristics. As discussed previously, the teachings of this disclosure could be implemented in a system which would maintain certain information regarding issues, such as a client on whose behalf work on an issue is performed, and notes created for the issue. The disclosure herein could allow a user [101] to search through the information related to issues, for example, using a dedicated search interface such as shown in
Of course, it should be understood that searching [107] is not limited to searching for issues as depicted in the exemplary interface of
After the search has been performed [107] the user [101] could be presented with the results of the search, for example, in the form of a list. The user [101] could then search the result list [109] to determine which issue is the most pressing, and then select [110] and begin work on that issue. Additionally, in some implementations, it is possible that the interface presented to the user [101] for the search of the results list [109] could include tools which could be used to facilitate or guide the search. To illustrate this, an example search result interface is shown in
Also, as shown in.
As another approach to assigning a priority for an issue, a priority could be automatically determined by a program as opposed to being assigned by the entity creating the issue. For example, the server [103] could be configured to consider data related to the issue such as its due date, the client (if any) the issue is associated with, whether the issue is billable, and other information in order to determine a priority. As an example of this approach, some systems could be implemented such with certain attributes having specific positive or negative effects on the priority (e.g., issues with closer due dates would be given higher priority; issues associated with high value/volume clients would be given higher priority; etc . . . ). Other variations are also possible. For example, the teachings of this disclosure could be implemented in a system where a priority would be assigned based on a combination of software calculation and user selection. For instance, a user selection of a priority category could result in the issue being assigned an initial value (e.g., 200 for normal) and that initial value could then be automatically modified based on other information about the issue (e.g., +50 for a deadline within less than five business days, −50 for nonbillable internal projects, etc . . . ). Accordingly, it should be understood that the explicitly disclosed techniques for assigning a priority are intended to be illustrative only, and should not be treated as limiting on claims included in this document or any related document.
In some implementations it might also be possible to modify the priority of an issue after it has initially been assigned. As with the initial definition of priorities, such modification could be programmatic, user driven, or both. As an example of programmatic modification of priorities, in some implementations, there could be software which would cause issues to increase in priority as their deadline approached. As another example, in some implementations, there could be information stored regarding the clients associated with issues, and the issue priorities could be updated as the client information is updated (e.g., if a client upgrades a service level agreement, then the priority for all issues associated with that client could be increased). As an example of human modification, in some implementations, this might take place simply by using an interface such as discussed above with respect to
f depicts an interface which could be used to modify the relative priorities of issues from a list [212] of results returned by a search. In some implementations, the reprioritization interface of
Continuing with the discussion of the activities shown in
In addition to (or as an alternative to, depending on the implementation) tools used to facilitate tracking of work done on an issue such as described, an interface such as shown in
Additionally, in some implementations, using a flag tool [222] might also result in the storage of data by the server [103] indicating that a “flag” had been created. This type of information could be used to create, for each user who had been indicated to receive a notification by a flag tool [222], a list of issues which had been “flagged” to that user. Such a list could be used as an alternative to the searching tools described previously when determining what issues should be worked on. Of course, it should be understood that the discussion of flagging in the context of
As shown in
While the discussion of
It should be understood that the example of using records to track physical equipment set forth above is intended to be illustrative only, and not limiting. Records, as well as the other types of information which could be maintained in a system implemented according to this disclosure could be used in a variety of settings. For example, in the sales context, the technology disclosed herein could be used to track and ensure follow up on sales leads (e.g., an issue might be to research and contact a particular prospect, a record might store social relationships of specific individuals, etc). Indeed, while special purpose implementations of the technology set forth herein could be created, the disclosure of this application is broadly applicable, and should not be limited to any particular subject matter or field of use.
Further, even in the context of issues and reporting, it should be understood that
Variations other than allowing non-browser interactions are supported as well. For instance, some individuals (e.g., contract employees who are hired for a specific project or task only) may not need to search for issues and decide what to work on. In such a case, software on a server [103] could be set up so that, if a user has permission to work on a single issue only, as soon as that user logged into the system, that user would automatically be clocked into that issue, and would be automatically clocked out again upon logging out. Alternatively, the user could be presented with a simplified interface which would allow the user to clock into/out of the particular assigned issue without having to log in/out of the system to do so. As another example of additional functionality which could be included, in some cases there could be interfaces for users who would only create issues (e.g., a tech support interface where users could submit requests for assistance) and would not need/want to search for other information in the system.
Another additional feature which could be used in a system for task tracking and allocation, consider the feature of permissions and access restrictions, which could be used to limit information which could be viewed, and acts which could be taken, by users. Such permissions and access restrictions could be specified in an implementation by organizing information stored for task tracking and allocation into folders, and giving users permissions relative to the specific folders. Such permissions might include permissions such as depicted in Table 1.
Following that structure, in some implementations there might also be groups of permissions implemented and given descriptive names so that a user could have their permissions defined by simply assigning a predefined group of permissions, rather than requiring individual permissions to be set separately. A set of exemplary permission groups is set forth below in Table 2.
Alternatively, or in addition to the folder based permissions described above, certain implementations could also include access controls and security measures which would be applied to individual entities (e.g., notes, issues, articles) or even data maintained for those entities (e.g., there might be different levels of permissions necessary to view text stored in a note than would be necessary to view the note itself). Additionally, in some implementations, different entities might have relationships which reach across folders and types of permissions. For example, in a case where records are used to allow users to track connections between physical pieces of networking equipment, it is possible that the physical connections between pieces of equipment might extent across folders. In such a case, it is possible that an exception could be written so that a user could follow the relationships of pieces of physical equipment even into folders which the user would not normally be able to access. Alternatively, the system might be configured such that the relationships with pieces of equipment located in folders the user could not access would be hidden from the user. Additional alternatives are also possible and could be implemented by those of ordinary skill in the art without undue experimentation in light of this disclosure.
Additionally, in some implementations, information stored for task tracking and allocation might be encrypted (or otherwise protected) so that it could not be accessed even if the database it was stored in was breached. As an example of an approach to this type of protection, in an implementation where information is organized into folders, if an individual folder is set as encrypted, then a passphrase could be used to encrypt (e.g., a hash on the passphrase as an encryption key, where the hash could be created using a one way hash algorithm such as MD5 or salted SHA256) the data for that folder before it is stored. Such a system might also include data which could be used to validate the passphrase (e.g., a version of the passphrase encrypted using salted SHA256 with a different salt than the encryption hash for the folder) before it was used to access the folder data. In operation, a two way encryption/decryption algorithm, such as AES or 3DES or Blowfish could be used to actually encrypt and decrypt the data.
Also, in some implementations there might be multiple levels of encryption necessary to unlock to reach a certain item of information. For example, in a case where there might be folders within folders, a user might be required to first unlock the parent folder, then unlock any subfolders before being able to access the information he or she was seeking. This could be achieved by repeatedly encrypting data, starting with encryption based on the passphrase for the highest level folder, then re-encrypting it with the passphrases applicable at each sub-folder level. Alternatively, it is also possible that data in a subfolder could be encrypted only a single time with a single passphrase formed by concatenating the passphrases for each folder level. Of course, the discussion above of multi-level encryption could easily be applied to forms of organization other than folders, such as projects, records, fields within issues or notes, etc. Accordingly, the discussion of encryption set forth above should be understood as being illustrative only, and not limiting.
Part of the disclosure, incorporated herein by reference in its entirety, is a computer program listing appendix containing code which can be used to implement certain features of the technology described herein. In particular, when used to configure a server, the code contained in the computer program listing appendix will allow users to (among other things) log in, search issues and create reports as described with reference to
As mentioned, the disclosure herein is intended only to illustrate the inventors' technology, and is not intended to disclose every possible implementation of that technology contemplated by the inventors. Numerous variations on, and departures from, the explicit disclosure of this application are contemplated by the inventors, and will be apparent to one of ordinary skill in the art in light of this application. Accordingly, the protection provided to the inventors by this document should not be limited to the material explicitly disclosed. Instead, such protection should be understood to be defined by the following claims, which are drafted to reflect the scope of protection sought by the inventors in this document when the terms in those claims which are listed below under the label “Explicit Definitions” are given the explicit definitions set forth therein, and the remaining terms are given their broadest reasonable interpretation, which should encompass the usage of terms presented herein, and be at least as broad as the broadest definitions given in a general purpose dictionary.
When used in the claims, “account” should be understood to refer to an entity on behalf of which actions can be taken and to which any costs associated with those actions can be attributed for purposes such as recordkeeping and billing. Examples of accounts include specific clients for a business, as well as internal cost centers a business might desire to define for cost tracking purposes.
When used in the claims, “based on” should be understood to mean that something is determined at least in part by the thing that it is indicated as being “based on.” When something is completely determined by a thing, it will be described as being “based EXCLUSIVELY on” the thing.
When used in the claims, “computer” should be understood to mean a device or group of devices which is capable of performing one or more logical and/or physical operations on data to produce a result.
When used in the claims, “computer executable instructions” should be understood to mean data which can be used to specify physical or logical operations which can be performed by a computer.
When used in the claims, a statement that a first thing “corresponds to” a second thing should be understood to mean that there is a one to one relationship between the first and second things. That is, only the first thing satisfies the relationship for the second thing, and only the second thing satisfies the relationship for the first thing.
When used in the claims, “data” means information which is represented in a form which is capable of being processed, stored and/or transmitted.
When used in the claims, “database” should be understood to refer to a discrete and identifiable set of information organized to facilitate the information's use and/or retrieval. For the purpose of clarity, it should be understood that a “database” can be a dedicated system (e.g., a server which serves purely as a repository of information), or could be integrated with other systems (e.g., a “database” could be stored on a server which is used for other tasks, potentially including the storage of other “databases”).
When used in the claims, “due date” should be understood to refer to a particular date on or before which a task should be completed. It should be understood that “due date” is not limited to calendar dates (e.g., Apr. 1, 2012), and also includes other types of dates, such as relative dates (e.g., in two weeks), or null dates (e.g., no due date).
When used in the claims, “indicate” (and various forms thereof) should be understood to refer to the act of showing the thing “indicated.”
When used in the claims, an “issue” should be understood to refer to data representing a unit of work product which needs to be created, or a defined unit of work which needs to be performed.
When used in the claims, “plurality” should be understood to refer to two or more. Accordingly, a statement that each X in a plurality of X's has some characteristic should be understood to mean that there are at least two X's having the characteristics listed, and should not be understood to mean that there are no X's which do not have characteristics listed.
When used in the claims, “priority” should be understood to refer to the precedence or importance of a thing.
When used in the claims, the verb “select” should be understood to refer to the act of picking out or otherwise specifically identifying the thing selected.
When used in the claims, a “set” should be understood to refer to a number, group, or combination of zero or more things of similar nature, design, or function.
When used in the claims, a statement that X is “specifically associated” with Y should be understood mean that either X is uniquely related to Y, Y is uniquely related to X, or both.
When used in the claims, “subject” should be understood to refer to a brief textual identification reflecting the general nature or a particular feature of an associated data entity.
When used in the claims, a statement that X is “uniquely related” to Y should be understood to mean that there is a particular set of operations which directly maps Y (and only Y) onto X. As an example of this relationship, a data object is uniquely related to its member variables, because there is a set of operations (e.g., a request for the member variable) which maps the member variables onto the data object.
This application is related to, claims priority from, and incorporates by reference in its entirety, provisional patent application 61/011,966, filed on Jan. 23, 2008, and having the same title and inventors as listed above.
