Prosecution Insights
Last updated: April 19, 2026
Application No. 18/300,951

MULTIUSER ACCESS RIGHTS FOR TRANSACTION MANAGEMENT

Non-Final OA §103§112
Filed
Apr 14, 2023
Examiner
CHOUAT, ABDERRAHMEN
Art Unit
2451
Tech Center
2400 — Computer Networks
Assignee
Wells Fargo Bank N A
OA Round
3 (Non-Final)
73%
Grant Probability
Favorable
3-4
OA Rounds
2y 8m
To Grant
77%
With Interview

Examiner Intelligence

Grants 73% — above average
73%
Career Allow Rate
195 granted / 267 resolved
+15.0% vs TC avg
Minimal +4% lift
Without
With
+4.0%
Interview Lift
resolved cases with interview
Typical timeline
2y 8m
Avg Prosecution
16 currently pending
Career history
283
Total Applications
across all art units

Statute-Specific Performance

§101
14.2%
-25.8% vs TC avg
§103
45.7%
+5.7% vs TC avg
§102
16.8%
-23.2% vs TC avg
§112
18.8%
-21.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 267 resolved cases

Office Action

§103 §112
Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Response to Arguments Regarding applicants arguments directed at the claim 1 amendments: Examiner respectfully notes the following: The amendment uses broad language such as “associate” and therefore Jamison teaches: wherein the collaborative goal is associated (the purpose is set by the creating user) with the primary user (user who created the channel; (Fig 3A; Channel creation request with “purpose” element 302 which can include a collaborative goal) and wherein the collaborative group of users comprises the primary user (user who created the channel; [0077] The term “channel creation request” refers to an electrically generated digital object that indicates that a user has provided an input comprising a request to create a group-based communication channel A channel creation request may be represented via a temporary code that notifies a recipient that a user has made the request. To provide further context, a channel creation request is generated in response to a user interaction with a group-based communication interface presented on a display screen of a client device. A user causes the client device to generate a channel creation request by interacting with, for example, a specific channel-creation actuator button that forms part of the group-based communication interface.) and other users (user invited to the channel) contributing to the collaborative goal; ([0086] The term “channel invitation interface component” refers to a user interface element that is rendered as part of a channel creation interface and is configured to enable a user to input channel invitation data indicative of at least one or more non-member users so that such one or more non-member users may be sent an invitation to join a group-based communication channel. For example, the channel invitation interface component 303 of FIG. 3A is an example of a channel invitation interface component. Examiner respectfully agrees that Jamison in view of Frank in view of Savage do not explicitly teach all of the recited claim amendments and points to Brooks: Brooks teaches a collaborative goal amount input element (determining by the system the number of points in the contribution pool for a specific task) configured to receive a numerical target value representing a collective goal amount (Fig 4; the display receives and output a total of 1000 contribution points) for the collaborative goal; (The system allots a pool size of points to be apportioned between user for the contribution by team members to the completion of a task see [0015-0017] [0061] In one illustrative embodiment, the request for quantifiable peer feedback may request that the recipient apportion a pool of points to each of the other team members identified in the request. Thus, for example, a pool of 1000 points may be made available and the recipient must apportion the 1000 points amongst the other team members. The size of the pool of points may be adjusted by the peer feedback system 310 based on a size of the team such that a fine enough relative evaluation of team members is received. That is, a pool size of 100 for a 10 person team may not provide as much insight into the relative performance of team members as a pool size of 1000. However, one does not want the pool size to be too large or else the recipient providing the quantitative feedback may be frustrated in trying to distribute so many points amongst the team members; see also 0066-0070; instead of numbers there’s also a percentage method) [0012] Collecting the quantifiable peer feedback may comprise providing a user interface in the request for apportioning a pool of points amongst the plurality of team members. The pool of points may be determined based on a number of team members in the plurality of team members. [0104] It should be noted that while the above illustrative embodiments are described in terms of a pool of points to be apportioned amongst a plurality of team members, the illustrative embodiments are not limited to such. Rather, other mechanisms for quantifying peer feedback may be utilized without departing from the spirit and scope of the present invention. Thus, for example, each team member may be given the same range of possible scores, e.g., 0 to 100, without a limitation that the total of all the scores add up to a particular total pool size. The relative contribution may then be determined based on a ratio of the individual team member's points to that of the total number of points allocated. Other quantitative mechanisms for evaluating the relative contribution of team members in a quantifiable manner may be used without departing from the spirit and scope of the present invention.) and an individual goal amount input element configured to receive a numerical value (apportioned contribution points) representing a personal contribution (each users personal contribution) toward the collaborative goal target amount. (apportion a number of points based on the contribution of team members; mapping above; Fig 4: [0061] In one illustrative embodiment, the request for quantifiable peer feedback may request that the recipient apportion a pool of points to each of the other team members identified in the request. Thus, for example, a pool of 1000 points may be made available and the recipient must apportion the 1000 points amongst the other team members. The size of the pool of points may be adjusted by the peer feedback system 310 based on a size of the team such that a fine enough relative evaluation of team members is received. That is, a pool size of 100 for a 10 person team may not provide as much insight into the relative performance of team members as a pool size of 1000. However, one does not want the pool size to be too large or else the recipient providing the quantitative feedback may be frustrated in trying to distribute so many points amongst the team members.) Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claim 1-5, 7-12, 14-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Regarding independent claim 1, the claim recites “a collaborative goal amount input element configured to receive a numerical target value representing a collective goal amount for the collaborative goal; and an individual goal amount input element configured to receive a numerical value representing a personal contribution toward the collaborative goal target amount.” While the specification recites a collaborative goal amount input element, and an individual goal amount input element, the specification does not recite that they are configured to receive a numerical value. Fig 4B the applicant points to in the response is not a “numerical target value” its specific to a dollar amount for investment and not any “numerical value” for any goal. Independent claims 8 and 15 inherit the same rejection as claim 1 above for reciting similar limitations. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claim(s) 1-2, 4, 7-9, 11, 14-16, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jamison et al. (US 20210026523 A1) in view of Frank et al. (US 20180197144 A1) in view of Savage et al. (US 20130179799 A1) in view of Brooks (US 20080195464 A1). Regarding claim 1, Jamison teaches a method comprising: ([0020] method) receiving a request, (receiving a request from a client device) at a server device, (0145; server device; 0066 group-based communication server)from a first client device (client device) to create a stored group of users associated with a primary user, ([0004] in execution with the at least one processor, cause the group-based communication apparatus to: receive, from a client device, a channel creation request associated with a group identifier; [0075] For example, only those users or administrators who have knowledge of and permission to access (e.g., a group-based communication channel identifier for the private group-based communication channel is associated with their user profile after the user has been validated/authenticated) the private group-based communication channel may view content of the private group-based communication channel. [0077] ) the primary user having a user profile stored on the server device (0154; retrieve user profile data associated with the user identifier of the user creating the channel from the group-based communication repository or “user profile stored on server device”); in response to the request, presenting a first user interface including: (0020; Figs 3A-3D; after the channel creation request displaying the interface screens [0084] The term “channel title interface component” refers to a user interface element that is rendered as a portion of a channel creation interface and is configured to enable a user to interact with the group-based communication system and enter a channel title or text string for a group-based communication channel. For example, the channel title interface components 301 of FIG. 3A-3D are examples of channel title interface components.) a selection element configured to receive a selection of users to include in the stored group; (0020; Figs 3A-4C; Fig 3C element 303 for selecting to add users) and an input text element configured to receive a label for the stored group; (Fig 3A-3C element 301 channel name) based on data received in the selection element and input text element, generating the stored group of users on the server device; (0149; [0149] FIG. 3A depicts an example channel creation interface 300 structured in accordance with various embodiments of the invention. The depicted channel creation interface 300 comprises a channel title interface component 301, a channel purpose interface component 302, a channel invitation interface component 303, a channel access settings element 304, and a channel create execution element 305. The channel creation interface 300 is rendered in response to receipt of a channel creation request associated with a group identifier. In some embodiments, the channel creation interface 300 is revealed and/or accessed once a user clicks on a plus icon visual indicator (e.g., “⊕”) (not shown) in relation to a “Channels” interface element (not shown) of a sidebar pane of a group-based communications interface (not shown). In other embodiments, the user clicks a “Create” interface element (not shown); 0151; The access settings element 304 in FIG. 3A is depicted as a toggle switch, however, other variations of the access settings element 304 are also contemplated by this disclosure as will be apparent to one of ordinary skill in the art. The depicted channel creation interface 300 further includes the channel create execution element 305, which is configured to allow a channel-creator user to indicate that the user wishes to create the group-based communication channel with the provided parameters and/or information) subsequent to the generating, presenting a second user interface including: ([0068] The term “group-based communication interface” is a graphical user interface of a group-based communication system that is configured to allow users to (e.g., group members) to view and engage a group-based communication workspace. A group-based communication interface is rendered to a client device based on data and instructions provided by the group-based communication system. In some embodiments, such data and instructions are facilitated by a dedicated software application running on the client device. In other embodiments, such data and instructions are provided through a web browser running on the client device. [0069] The term “group-based communication channel” refers to a virtual communications environment or feed that is configured to display messaging communications posted by channel members (e.g., validated users accessing the environment using client devices) that are viewable only to the members of the channel. The format of the group-based communication channel may appear differently to different members of the group-based communication channel; however, the content of the group-based communication channel (i.e., messaging communications) will be displayed to each member of the group-based communication channel. For instance, a common set of group-based messaging communications will be displayed to each member of the respective group-based communication channel such that the content of the group-based communication channel (i.e., messaging communications) will not vary per member of the group-based communication channel.) icon representations of each user in the stored group; (Examiner respectfully notes that slack has been well known to include user icons in group chats from the time of its inception in 2014) receiving a collaborative goal request to create a collaborative goal from the primary user; (Fig 3A; Channel creation request with “purpose” element 302 which can include a collaborative goal) presenting a user interface configured to receive user selections for the collaborative goal; (Fig 3A; Channel creation request with “purpose” element 302 which can include a collaborative goal) generating a collaborative group of users on the server device ([0149] FIG. 3A depicts an example channel creation interface 300 structured in accordance with various embodiments of the invention. The depicted channel creation interface 300 comprises a channel title interface component 301, a channel purpose interface component 302, a channel invitation interface component 303, a channel access settings element 304, and a channel create execution element 305. The channel creation interface 300 is rendered in response to receipt of a channel creation request associated with a group identifier. In some embodiments, the channel creation interface 300 is revealed and/or accessed once a user clicks on a plus icon visual indicator (e.g., “⊕”) (not shown) in relation to a “Channels” interface element (not shown) of a sidebar pane of a group-based communications interface (not shown). In other embodiments, the user clicks a “Create” interface element (not shown); 0151; The access settings element 304 in FIG. 3A is depicted as a toggle switch, however, other variations of the access settings element 304 are also contemplated by this disclosure as will be apparent to one of ordinary skill in the art. The depicted channel creation interface 300 further includes the channel create execution element 305, which is configured to allow a channel-creator user to indicate that the user wishes to create the group-based communication channel with the provided parameters and/or information) based on the received user selections for the collaborative goal; (Fig 3A; Channel creation request with “purpose” element 302 which can include a collaborative goal; [0053] Channel titles are established at creation of each respective group-based communication channel Because channel titles serve as a consistent identifier for the associated group-based communication channel, it is important that users construct channel titles from which group members can readily understand the purpose of the group-based communication channel based simply on the channel title. [0087] The term “group-defined channel title template” refers to a group-wide nomenclature, formatting structure, field array, and/or layout of a channel title for a group-based communication channel when such channel is created so that group members may readily understand the purpose of any associated group-based communication channel.) wherein the collaborative goal is associated (the purpose is set by the creating user) with the primary user (user who created the channel; (Fig 3A); Channel creation request with “purpose” element 302 which can include a collaborative goal) and wherein the collaborative group of users comprises the primary user (user who created the channel; [0077] The term “channel creation request” refers to an electrically generated digital object that indicates that a user has provided an input comprising a request to create a group-based communication channel A channel creation request may be represented via a temporary code that notifies a recipient that a user has made the request. To provide further context, a channel creation request is generated in response to a user interaction with a group-based communication interface presented on a display screen of a client device. A user causes the client device to generate a channel creation request by interacting with, for example, a specific channel-creation actuator button that forms part of the group-based communication interface.) and other users (user invited to the channel) contributing to the collaborative goal; ([0086] The term “channel invitation interface component” refers to a user interface element that is rendered as part of a channel creation interface and is configured to enable a user to input channel invitation data indicative of at least one or more non-member users so that such one or more non-member users may be sent an invitation to join a group-based communication channel. For example, the channel invitation interface component 303 of FIG. 3A is an example of a channel invitation interface component. Jamison does not explicitly teach and a selectable graphic element configured to present a permission modification interface for a first user in the stored group with respect to accounts of the primary user; and in response to receiving input in the permission modification interface, updating access rights of the first user for an account of the accounts of the primary user; and and presenting, with respect to the collaborative goal: a collaborative goal amount input element configured to receive a numerical target value representing a collective goal amount for the collaborative goal; and an individual goal amount input element configured to receive a numerical value representing a personal contribution toward the collaborative goal target amount. In an analogous art Frank teaches and a selectable graphic element configured to present a permission modification (access control rights) interface for a first user (group admin or super admin) in the stored group with respect to accounts of the primary user; (0044; [0044] The term “access rights” refers to parameters for controlling the ability of users to view, change, navigate, and execute contents of the group-based communication system. [0049] For example, if a user is associated with a global identifier, this may signify that the user is able to access an enterprise directed channel. In some embodiments, only super administrators have the ability to edit messages in an enterprise directed channel. All other members of the enterprise directed channel may only access (but not edit or delete) messages in the enterprise directed channel. For example, a super administrator may define access control rights for which members of the organization or enterprise may create an enterprise directed channel type and also which members of the organization or enterprise may post (e.g., write) messages in the enterprise directed channel type. [0056] Users identified as group administrators may edit the access control rights to a group or group-based communication channel which the group is a part of. Group administrators may also add users to the group or group-based communication channel which the group is a part of or to invite users to a group or group-based communication channel which the group is a part of. The access control parameters editable by the group administrator may be limited by the settings set by a super administrator. See also 0006; 0057) and in response to receiving input in the permission modification interface, (access control rights; or assigning admin rights) updating access rights of the first user for an account of the accounts of the primary user.(the profile of the user that had access control rights) (Mapping above; [0060] The term “enterprise storage location” refers one or more storage locations in a group-based communication repository for storing messages that are associated with group-based communication channels, excluding messages that are associated with private group-based communication channels. Each group-based communication channel may be assigned its own partition inside the enterprise storage location. Location within the definition of enterprise storage location may refer to a location in memory where data is stored (e.g., a memory address) or to a portion of memory with distinct access control parameters. For example, the enterprise storage location may require different parameters for access than for access to a group storage location. See also 0107; 0109; It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Jamison] to include [interface for adjusting and editing access control] as is taught by [Frank]. The suggestion/motivation for doing so is to [improve collaboration - Background]. Jamison in view of Frank do not explicitly teach and and presenting, with respect to the collaborative goal: a collaborative goal amount input element configured to receive a numerical target value representing a collective goal amount for the collaborative goal; and an individual goal amount input element configured to receive a numerical value representing a personal contribution toward the collaborative goal target amount. In an analogous art Savage teaches and presenting, with respect to the collaborative goal: a collaborative goal amount input element; (aggregate status) and an individual goal amount input element (individual status) (Fig 9-10; 14; [0097] FIG. 10 depicts a screenshot showing an example of a user interface 1000 which can be used for reviewing assigned tasks 1002 and updating task statuses 1004. For example, a delegate (or a user who has been assigned a task) can use drop down menu 1004 to update the status of a task which he/she has been assigned through the user interface. The user interface can thus depict the aggregate status of tasks assigned to multiple collaborators. [0092] In process 712, a change in status of the task performed by the given other user is detected. In process 714, the status of the task is updated in the unified user interface for commenting. The status updates can include, for example, a completed status, an incomplete status or an in progress status. 0067; For example, the access tracking engine 507 may track the ordering in which tasks are performed such that task statuses can be appropriately updated and reflected to each user working on the same file. ) It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Jamison in view of Frank] to include [individual and aggregate completion towards the task] as is taught by [savage]. The suggestion/motivation for doing so is to [improve collaboration - Background]. Jamison in view of Frank in view of Savage do not explicitly teach the underlined a collaborative goal amount input element configured to receive a numerical target value representing a collective goal amount for the collaborative goal; and an individual goal amount input element configured to receive a numerical value representing a personal contribution toward the collaborative goal target amount. In an analogous art Brooks teaches a collaborative goal amount input element (determining by the system the number of points in the contribution pool for a specific task) configured to receive a numerical target value representing a collective goal amount (Fig 4; the display receives and output a total of 1000 contribution points) for the collaborative goal; (The system allots a pool size of points to be apportioned between user for the contribution by team members to the completion of a task see [0015-0017] [0061] In one illustrative embodiment, the request for quantifiable peer feedback may request that the recipient apportion a pool of points to each of the other team members identified in the request. Thus, for example, a pool of 1000 points may be made available and the recipient must apportion the 1000 points amongst the other team members. The size of the pool of points may be adjusted by the peer feedback system 310 based on a size of the team such that a fine enough relative evaluation of team members is received. That is, a pool size of 100 for a 10 person team may not provide as much insight into the relative performance of team members as a pool size of 1000. However, one does not want the pool size to be too large or else the recipient providing the quantitative feedback may be frustrated in trying to distribute so many points amongst the team members; see also 0066-0070; instead of numbers there’s also a percentage method) [0012] Collecting the quantifiable peer feedback may comprise providing a user interface in the request for apportioning a pool of points amongst the plurality of team members. The pool of points may be determined based on a number of team members in the plurality of team members. [0104] It should be noted that while the above illustrative embodiments are described in terms of a pool of points to be apportioned amongst a plurality of team members, the illustrative embodiments are not limited to such. Rather, other mechanisms for quantifying peer feedback may be utilized without departing from the spirit and scope of the present invention. Thus, for example, each team member may be given the same range of possible scores, e.g., 0 to 100, without a limitation that the total of all the scores add up to a particular total pool size. The relative contribution may then be determined based on a ratio of the individual team member's points to that of the total number of points allocated. Other quantitative mechanisms for evaluating the relative contribution of team members in a quantifiable manner may be used without departing from the spirit and scope of the present invention.) and an individual goal amount input element configured to receive a numerical value (apportioned contribution points) representing a personal contribution (each users personal contribution) toward the collaborative goal target amount. (apportion a number of points based on the contribution of team members; mapping above; Fig 4: [0061] In one illustrative embodiment, the request for quantifiable peer feedback may request that the recipient apportion a pool of points to each of the other team members identified in the request. Thus, for example, a pool of 1000 points may be made available and the recipient must apportion the 1000 points amongst the other team members. The size of the pool of points may be adjusted by the peer feedback system 310 based on a size of the team such that a fine enough relative evaluation of team members is received. That is, a pool size of 100 for a 10 person team may not provide as much insight into the relative performance of team members as a pool size of 1000. However, one does not want the pool size to be too large or else the recipient providing the quantitative feedback may be frustrated in trying to distribute so many points amongst the team members.) It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Jamison in view of Frank in view of Savage] to include [task numerical values, and contribution values] as is taught by [Brooks]. The suggestion/motivation for doing so is to [improve collaboration feedback [0001-0005] Regarding claim 2, Jamison in view of Frank in view of Savage in view of Brooks teach the method of claim 1, and is disclosed above, Jamison in view of Frank do not explicitly teach further comprising: presenting a third user interface including: an identifier of a goal of the primary user; a status of the goal; and an icon representation of users in the stored group that have contributed towards the goal. In an analogous art Savage teaches presenting a third user interface including: (see images interface) an identifier of a goal of the primary user; (task of a user) a status of the goal; (status of the task) and an icon representation of users (user comments include icons) in the stored group that have contributed towards the goal (users who commented on the task and by giving input “contributed”) (Figs 8-15; [0096] For example, data field 902 and 904 can be used to view, update or edit tasks assigned to one or more users or collaborators. In addition, the status of various assigned tasks can be depicted in the same user interface allowing the delegates to also comment on their assigned tasks. Field 906 depicts a list of users or collaborators which have been assigned various tasks related to the file `conferencePresentation.ppt` and can also depict an indication of the status (e.g., via (v) (x) or (?) of the status of the assigned tasks) It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Jamison in view of Frank] to include [displaying assigned task, their status, and users contributing] as is taught by [savage]. The suggestion/motivation for doing so is to [improve collaboration - Background]. Regarding claim 4, Jamison in view of Frank in view of Savage in view of Brooks teach the method of claim 2, and is disclosed above, further comprising: receiving a goal viewing request from a second user, the second user being in the group of users, to view the goal of the primary user; (0028; collaborators; 0046; Through the same user interface, task status and updates from multiple users or collaborators can be indicated and reflected. In some instances, the users can perform the tasks (e.g., review or approve or reject, etc.) via the same user interface.) in response to the goal viewing request, presenting a fourth user interface, (Fig 14; 0028; collaborators; 0046; Through the same user interface, task status and updates from multiple users or collaborators can be indicated and reflected. In some instances, the users can perform the tasks (e.g., review or approve or reject, etc.) via the same user interface.) the fourth user interface identifying contributions made by other users in the group of users to the goal of the primary user; (Fig 14; comments contributed by other user to the task) receiving a contribution amount from the second user towards the goal; (0069-0071; receiving a comment from the user; [0069] Actionable events can be created by the actionable events manager 515 and can include by way of example but not limitation, an assigned task such as, a task for another user to review the work item, a task for another user to update or approve the work item, a task for another user to edit or comment on the work item, etc. For example, through a request received from the edit/access request processor 505, the actionable event manager 515 can identify, detect, parse, retrieve, and/or analyze any request to create or generate an actionable event; See also Figs 9-10 and [0096] For example, data field 902 and 904 can be used to view, update or edit tasks assigned to one or more users or collaborators. In addition, the status of various assigned tasks can be depicted in the same user interface allowing the delegates to also comment on their assigned tasks. Field 906 depicts a list of users or collaborators which have been assigned various tasks related to the file `conferencePresentation.ppt` and can also depict an indication of the status (e.g., via (v) (x) or (?) of the status of the assigned tasks. [0097] FIG. 10 depicts a screenshot showing an example of a user interface 1000 which can be used for reviewing assigned tasks 1002 and updating task statuses 1004. For example, a delegate (or a user who has been assigned a task) can use drop down menu 1004 to update the status of a task which he/she has been assigned through the user interface. The user interface can thus depict the aggregate status of tasks assigned to multiple collaborators.) and in response to receiving the contribution: transmitting a notification to each user in the group of users; (0052; In one embodiment, a commenting user interface or a comment action associated with a notification 0069-0071; [0070] The task generator 517 can generate/create the task on receiving the request and assign it to a relevant user if applicable (e.g., via the task delegator 518). In one embodiment, the task is assigned to the relevant user upon verification by the permission manager 506 that the assigned user has the appropriate rights and permissions. In delegating the tasks, the task delegator 518 presents the task to the delegate such that it is accessible via their login, for example, through a commenting or status update/feed user interface. For example, the assigned task can be depicted through a page for the work space with which the given file is associated used for commenting. The assigned task can also be depicted through a page where status updates or feeds regarding files or work spaces are showing. [0071] In one embodiment, the task status tracker and updator 519 detects, tracks, monitors, updates, the status of any actionable event which has been created or assigned to users/collaborators. The status tracker/updator 519, upon detecting a status change (e.g., item updated, item approved, rejected, in progress, etc.) or upon completion of a task, can update the user interface such that a current status is indicated and reflected, for example, generally also in an integrated fashion with a user interface where comments or status updates are depicted/submitted and/or from where the tasks were created. A delegate can also directly update a task status through a unified user interface where task assignment features are integrated with commenting/status update functionalities, as further illustrated in the example screenshots of FIG. 15.) and adding a message in a group chat messaging interface indicating the contribution amount. (0052; In one embodiment, a commenting user interface or a comment action associated with a notification 0070; commenting or status update/feed user interface. 0071; generally also in an integrated fashion with a user interface where comments or status updates are depicted/submitted and/or from where the tasks were created.) It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Jamison in view of Frank] to include [displaying assigned task, their status, a user contributing] as is taught by [savage]. The suggestion/motivation for doing so is to [improve collaboration - Background]. Regarding claim 7, Jamison in view of Frank in view of Savage teach the method of claim 1, further comprising: Jamison in view of Frank do not teach but Savage teaches receiving a request from the primary user to view a status of the collaborative goal; (Mapping above + [0097] FIG. 10 depicts a screenshot showing an example of a user interface 1000 which can be used for reviewing assigned tasks 1002 and updating task statuses 1004. For example, a delegate (or a user who has been assigned a task) can use drop down menu 1004 to update the status of a task which he/she has been assigned through the user interface. The user interface can thus depict the aggregate status of tasks assigned to multiple collaborators. and in response: presenting a collaborative goal overview user interface including: (mapping above; [0097] FIG. 10 depicts a screenshot showing an example of a user interface 1000 which can be used for reviewing assigned tasks 1002 and updating task statuses 1004. For example, a delegate (or a user who has been assigned a task) can use drop down menu 1004 to update the status of a task which he/she has been assigned through the user interface. The user interface can thus depict the aggregate status of tasks assigned to multiple collaborators.) a combined contribution amount of the collaborative group of users; (mapping above; aggregate status of tasks) Jamison in view of Frank in view of Savage do not explicitly teach and a percentage amount contribution of each individual in the collaborative group of users. In an analogous art Brooks teaches and a percentage amount contribution of each individual in the collaborative group of users. ([0016] Moreover, calculating statistical representations of each team member's relative contribution to completion of the task based on the collected quantifiable peer feedback scores may comprise calculating a team percentile for each team member. Generating one or more reports may comprise generating a team percentile graph based on totals of apportioned points for each team member. [0017] Furthermore, calculating statistical representations of each team member's relative contribution to completion of the task based on the collected quantifiable peer feedback scores may comprise calculating a score percentile for each team member. Generating one or more reports may comprise generating a score percentile graph based on totals of apportioned points for each team member.) It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Jamison in view of Frank in view of Savage] to include [task contribution percentage] as is taught by [Brooks]. The suggestion/motivation for doing so is to [improve collaboration feedback [0001-0005]]. Regarding claim 8, the claim inherits the same rejection as claim 1 for reciting similar limitations in the form of a non-transitory computer readable medium (0035; of a non-transitory computer readable medium) Regarding claim 9, the claim inherits the same rejection as claim 2 for reciting similar limitations in the form of a non-transitory computer readable medium (0035; of a non-transitory computer readable medium) Regarding claim 11, the claim inherits the same rejection as claim 4 for reciting similar limitations in the form of a non-transitory computer readable medium (0035; of a non-transitory computer readable medium) Regarding claim 14, the claim inherits the same rejection as claim 7 for reciting similar limitations in the form of a non-transitory computer readable medium (0035; of a non-transitory computer readable medium) Regarding claim 15, the claim inherits the same rejection as claim 1 for reciting similar limitations in the form of a system (0052; communication system) Regarding claim 16, the claim inherits the same rejection as claim 2 for reciting similar limitations in the form of a system (0052; communication system) Regarding claim 18, the claim inherits the same rejection as claim 4 for reciting similar limitations in the form of a system (0052; communication system) Claim(s) 3, 10 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jamison et al. (US 20210026523 A1) in view of Frank et al. (US 20180197144 A1) in view of Savage et al. (US 20130179799 A1) in view of Brooks (US 20080195464 A1) in view of Childress et al. (US 20200053091 A1). Regarding claim 3, Jamison in view of Frank in view of Savage in view of Brooks teach the method of claim 2, and is disclosed above, Jamison in view of Frank in view of Savage in view of Brooks do not explicitly teach further comprising: receiving an access rights change request from a client device associated with the primary user to remove goal status access rights of the goal for a second user in the stored group; and in response to the access rights change request, updating viewing access rights of the second user with respect to the goal. In an analogous art Childress teaches receiving an access rights change request from a client device associated with the primary user to remove goal status access rights of the goal for a second user in the stored group; (the admin removes user access permission based on status and completion) and in response to the access rights change request, updating viewing access rights of the second user with respect to the goal. (access right have been removed)( [0055] An administration application can manage authorization for a user of an application. The administration application can provide access to view and modify data. This access can be based on the user's administration group membership and/or additional settings that can be determined by the application administrator role. The administration application can manage who can view or modify information in a flexible and extensible way. The administration application can provide access based on the authorized user's authorization level at a specific point in time. The administration application can leverage the CRUD pattern to determine what access is available by route, component, function, and other means. The CRUD permission can be used to set-up or modify the user experience based on the user's authorization settings at a point in time. [0060] For example, a team of users can be involved in the development of a software application. During the initial period of development when many users are writing and editing source code, all users on the team can have extensive access permissions. As development progresses and certain tasks are completed, access permissions can be removed from the users responsible for the completed tasks. In addition, as the development process requires new tasks additional users can be granted access permissions or the scope of permissions for existing users can be extended. For example, if the software application requires beta testing, users responsible for beta testing can be granted “read” permissions, or other access permissions necessary for their work without foresaid software application modifications. Once the software application is completed and deployed, access permissions for many users responsible for development can be reduced or revoked. Users responsible for supporting and maintaining the application during operation can receive the required access permissions.) It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Jamison in view of Frank in view of Savage in view of Brooks] to include [remove access rights based on status] as is taught by [Childress]. The suggestion/motivation for doing so is to [improve access permissions]. Regarding claim 10, the claim inherits the same rejection as claim 3 for reciting similar limitations in the form of a non-transitory computer readable medium (0035; of a non-transitory computer readable medium) Regarding claim 17, the claim inherits the same rejection as claim 3 for reciting similar limitations in the form of a system (0052; communication system) Claim(s) 5, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jamison et al. (US 20210026523 A1) in view of Frank et al. (US 20180197144 A1) in view of Savage et al. (US 20130179799 A1) in view of Brooks (US 20080195464 A1) in view of Baez et al. (US 20230090799A1) Regarding claim 5, Jamison in view of Frank in view of Savage in view of Brooks teach the method of claim 1, and is disclosed above, Jamison further comprising: in response to receiving the collaborative goal request, presenting a third user interface including: (0020; Figs 3A-3D; after the channel creation request displaying the interface screens [0084] The term “channel title interface component” refers to a user interface element that is rendered as a portion of a channel creation interface and is configured to enable a user to interact with the group-based communication system and enter a channel title or text string for a group-based communication channel. For example, the channel title interface components 301 of FIG. 3A-3D are examples of channel title interface components.) a first user selection portion identifying contacts of the primary user that have accounts on the server device; (0159-0160; identified users are searchable by their usernames or are members of an organization, and users have profiles and user accounts; [0052] A group-based communication system may have multiple group-based communication workspaces, each group-based communication workspace dedicated to a particular organizational group or team having a defined member list (i.e., a defined list of authenticated user accounts). Each group-based communication workspace includes a plurality of group-based communication channels. Users communicate with one another via the group-based communication channels.) wherein generating the collaborative group of users on the server device([0149] FIG. 3A depicts an example channel creation interface 300 structured in accordance with various embodiments of the invention. The depicted channel creation interface 300 comprises a channel title interface component 301, a channel purpose interface component 302, a channel invitation interface component 303, a channel access settings element 304, and a channel create execution element 305. The channel creation interface 300 is rendered in response to receipt of a channel creation request associated with a group identifier. In some embodiments, the channel creation interface 300 is revealed and/or accessed once a user clicks on a plus icon visual indicator (e.g., “⊕”) (not shown) in relation to a “Channels” interface element (not shown) of a sidebar pane of a group-based communications interface (not shown). In other embodiments, the user clicks a “Create” interface element (not shown); 0151; The access settings element 304 in FIG. 3A is depicted as a toggle switch, however, other variations of the access settings element 304 are also contemplated by this disclosure as will be apparent to one of ordinary skill in the art. The depicted channel creation interface 300 further includes the channel create execution element 305, which is configured to allow a channel-creator user to indicate that the user wishes to create the group-based communication channel with the provided parameters and/or information) is further based on user selections made in the first user selection portion, (Figs 3A-4A; see 4A includes purpose and the creation of the channel) and transmitting invitation requests to users associated with the user selections. (mapping above + [0017] In some embodiments, the channel creation interface further comprises a channel invitation interface component and the group-based communication apparatus is further configured to receive channel invitation input entered in the channel invitation interface component, wherein the channel invitation input comprises an indication of at least one user recipient to be sent an invitation to join the group-based communication channel; and determine the first channel title suggestions set based on the group-defined format protocol of the group-defined channel title template and based upon the channel invitation input.) Jamison in view of Frank in view of Savage in view of Brooks do not explicitly teach the underlined and a second user selection portion identifying contacts of the primary user that do not have accounts on the server device; based on user selections made in the first user selection portion and the second user selection portion, In an analogous art Baez teaches a second user selection portion identifying contacts of the primary user that do not have accounts on the server device; (0065; guest invitation to a shared channel and workspace, as well as re-activating user accounts and inviting users of the reactivated account. As a non-limiting example, the settings and permissions can include managing how users join the account, managing shared channel permissions, establishing organizational policies, setting channel management tools and/or preferences, defining one or more default settings (e.g., do not disturb hours, channels for new users, languages of a workspace or organization, etc.), or the like. As a non-limiting example, management of members, channels, and workspaces can include customizations (e.g., user profiles, workspaces, display names, managing duplicate users, channels, etc.), inviting new users to a workspace, deactivate or reactivate a user account, or the like. As a non-limiting example, a configuration of access and security can include setting default sign-ins for users, user authentication, guest invitation permissions, reset of single sign-on sessions, modifying a single sign-on provider, establishing security and data policies for shared channels, direct messaging instances, and/or workspaces, and the like.) based on user selections made in the second user selection portion, generating a collaborative group of users on the server device; and transmitting invitation requests to users associated with the user selections. (Mapping above + 0079; the system sends out invitations; 0106 steps are performed by a server) It would have been obvious to one of ordinary skill in the art prior to the effective filing of the application to modify the teachings of [Jamison in view of Frank in view of Savage in view of Brooks] to include [inviting users that did not have an account, or a guest, or a new user] as is taught by [Baez]. The suggestion/motivation for doing so is to [organization in communication platform [0001]]. Regarding claim 12, the claim inherits the same rejection as claim 5 for reciting similar limitations in the form of a non-transitory computer readable medium (0035; of a non-transitory computer readable medium) Regarding claim 19, the claim inherits the same rejection as claim 5 for reciting similar limitations in the form of a system (0052; communication system) Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDERRAHMEN H CHOUAT whose telephone number is (571)431-0695. The examiner can normally be reached on Mon-Fri from 9AM to 5PM. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry, can be reached at telephone number 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice. Abderrahmen Chouat Examiner Art Unit 2451 /Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Read full office action

Prosecution Timeline

Apr 14, 2023
Application Filed
May 31, 2025
Non-Final Rejection — §103, §112
Sep 03, 2025
Response Filed
Oct 21, 2025
Final Rejection — §103, §112
Dec 12, 2025
Response after Non-Final Action
Jan 08, 2026
Request for Continued Examination
Jan 25, 2026
Response after Non-Final Action
Feb 06, 2026
Non-Final Rejection — §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12596793
SYSTEM AND METHOD FOR PATTERN-BASED DETECTION AND MITIGATION OF COMPROMISED CREDENTIALS
2y 5m to grant Granted Apr 07, 2026
Patent 12592919
RE-AUTHENTICATION KEY GENERATION
2y 5m to grant Granted Mar 31, 2026
Patent 12593197
APPLICATION REQUIREMENTS FOR VEHICLE-TO-EVERYTHING APPLICATIONS
2y 5m to grant Granted Mar 31, 2026
Patent 12547911
CHARACTERIZING A COMPUTERIZED SYSTEM BASED ON CLUSTERS OF KEY PERFORMANCE INDICATORS
2y 5m to grant Granted Feb 10, 2026
Patent 12549643
PUSH NOTIFICATION DISTRIBUTION SYSTEM
2y 5m to grant Granted Feb 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
73%
Grant Probability
77%
With Interview (+4.0%)
2y 8m
Median Time to Grant
High
PTA Risk
Based on 267 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month