DETAILED ACTION
The objection to the specification is withdrawn based on amendments filed 04/22/2026.
The 112(b) rejection is withdrawn based on the amendments filed 04/22/2026.
Claims 2, 9 and 16 are canceled.
Claims 1, 3-8, 10-15, and 17-20 are pending.
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 Applicant’s argument that Weiss and Frank do not teach “determining an access level of the user device based on the user’s identity and an address associated with the user device being on an allowlist”, this argument is moot in view of new grounds of rejection.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 3, 4, 8, 10, 11, and 15, 17, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication 20210167949 A1 to Weiss et al. (Weiss) in view of U.S . Patent Publication 20210264368 A1 to Frank et al. (Frank).
Regarding claim 1, Weiss teaches a system for data accessibility and management in a distributed network, the system comprising: a processing device (Weiss [0153], e.g., The computer architecture 600 illustrated in FIG. 21 includes a central processing unit 602); a non-transitory storage device containing instructions (Weiss [0154-0155], e.g., The mass storage device 612 and its associated computer-readable media); when executed by the processing device, causes the processing device to perform the steps of: generate an interaction interface (Weiss [0132], e.g., An example user interface 401 of a channel is illustrated in FIG. 19A), wherein the interaction interface comprises a channel (Weiss [0132], e.g., In this example, the group, e.g., the channel, includes a single member 107A; Fig. 19A, e.g., element 401), and wherein the interaction interface comprises input from a user (Weiss [0132], e.g., a channel includes a communication session that allows users to join public or private groups. Once a member, users can share messages and other forms of data with other members); receive, via a user device, an authentication from the user device, wherein the authentication authenticates the user’s identity (Weiss [0088-0089], e.g., the user's token is an access token which is obtained by the client when a user logs in with their credentials…… The token contains the user's ID and when validated can be trusted as representing the user's consent to undertake an action…… the server 120…… can utilize one or more techniques to authenticate users on each system); determine an access level of the user device based on the user’s identity [and an address associated with the user device being on an allowlist] (Weiss [0067], e .g., the server 120 can send a verification request 121 to the group manager 115 to verify the membership status of each requesting user…… the group manager 115 can access records, such as a group roster 116 defining the members of each group, to determine if one or more users are current members of a group. Individual records may indicate a Group ID 112 and User IDs 113 for each member. Individual records may also indicate specific permissions and roles for each User ID); allow the user, via the user device, to access the channel based on the access level of the user device (Weiss [0132], e.g., Once a member, users can share messages and other forms of data with other members); receive an attachment, wherein the input comprises the attachment, and wherein the attachment is uploaded to the interaction interface via the user (Weiss [0132], e.g., users can share messages and other forms of data with other members; [0146], e.g., A communication session can be managed by a system that can share text messages, data files, video fees, live video and audio or other forms of data; Fig. 19A, e.g., element 401, Shared Data File); encrypt the input, wherein encrypting the input comprises securing the input to prevent unauthorized access to the input (Weiss [0141], e.g., The vault key 104 can then enable the second client device 110B to generate an encrypted secret key 2 102B′ from a secret key 2 102B, the secret key 2 102B enabling the second client device 110B to generate encrypted secret data 2 101B′ from secret data 2 101B); store the input in a database, wherein the database is associated with an entity that hosts the interaction interface (Weiss [0142], e.g., To store the encrypted data at the server 120, the client device 110B can send a write request 158 the server requesting the server 120 to store the encrypted secret data 2 101B′, the encrypted secret key 2 102B′, and the encrypted vault key 2 104B′ in the vault 109 in association with the second user 107B. The write request 158 can include the encrypted data (as shown) or the write request 158 can be sent independently from the encrypted data); and transfer the input to a destination, wherein the destination is chosen by the user (Weiss Fig. 19A, e.g., Carol sent two messages to First Project / Shipped active channel), and wherein the destination is a destination device (Weiss Fig. 19A, e.g., Carol sent messages to active channel, Seth and Jeff received messages).
Weiss does not explicitly teach, but Frank teaches determine an access level of the user device based on the user’s identity and an address associated with the user device being on an allowlist (Frank [0113], e.g., The user identification may be a user's email address…… a unique hardware identifier of a user's client device, IP address of a user's client device; [0120], e.g., access to the group is limited to users that have been selected by the group administrator or super administrator. The authorized users can be indicated by a global identifier or user identification; [0056], e.g., The term “private channel type” refers to a data type associated with a group-based communication channel within an enterprise that indicates to a group-based communication server a defined authorized list (i.e., whitelist) of user identifiers (e.g., user identifiers, global identifiers) associated with users who are allowed to access the group-based communication channel; [0069], e.g., The term “whitelist” should be understood to refer to access control parameters that indicate to a group-based communication server one or more members of a group-based communication system allowed to take an action (e.g. joining a channel or group); Also see paragraphs [0124]-[0132]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Weiss with the teachings of Frank with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of strengthening user verification by storing multiple user identifiers (Frank [0113], e.g., In some embodiments, a user may have multiple user identifications associated with their global identifier to better verify it is the same user. For example, a user identification may include a user's driver's license number and email address. This way if the user changes email addresses, then at least the user's driver's license number may remain the same so that there is a better chance of uniquely identifying the user according to user identification. Unique user identification is especially important where users of the group-based communication system belong (or previously belonged) to multiple organizations that use the group-based communication system).
Regarding claim 3, most of the limitations of this claim have been noted in the rejection of claim 1. Weiss further teaches wherein the channel comprises a secure channel (Weiss [0132], e.g., a channel includes a communication session that allows users to join public or private groups. Once a member, users can share messages and other forms of data with other members), wherein the secure channel comprises a secure designation that indicates the channel is used to transfer sensitive information (Weiss Fig. 19A, e.g., Carol send a file containing a schedule a specific group e.g., First Product/Shipping).
Weiss does not explicitly teach, but Frank teaches wherein executing the instructions further causes the processing device to allow the user, via the user device, to access the secure channel based on the access level of the user device (Frank [0051], e.g., In a private group-based communication channel type, access control parameters may comprise a whitelist of user identifiers who are allowed to access the group-based communication channel. For example, access control parameters may specifically detail certain user identifiers or global identifiers associated with users who may be allowed access to a private group-based communication channel associated with the enterprise promoted channel type).
The motivation to combine is the same as that of claim 1.
Regarding claim 4, most of the limitations of this claim have been noted in the rejection of claim 1. Weiss further teaches to: receive, via an additional user device of an additional user, an additional authentication from the additional user device, wherein the additional authentication authenticates the additional user’s identity; (Weiss [0088-0089], e.g., the user's token is an access token which is obtained by the client when a user logs in with their credentials…… The token contains the user's ID and when validated can be trusted as representing the user's consent to undertake an action…… the server 120…… can utilize one or more techniques to authenticate users on each system); determine an access level of the additional user device based on the additional user’s identity [and an address associated with the additional user device] (Weiss [0067], e.g., the server 120 can send a verification request 121 to the group manager 115 to verify the membership status of each requesting user…… the group manager 115 can access records, such as a group roster 116 defining the members of each group, to determine if one or more users are current members of a group. Individual records may indicate a Group ID 112 and User IDs 113 for each member. Individual records may also indicate specific permissions and roles for each User ID; [0134], e.g., the membership data 165 indicates that the second user is a new member of the group); and allow the additional user, via the additional user device, to access the channel based on the access level of the additional user device (Weiss [0132], e.g., Once a member, users can share messages and other forms of data with other members).
Weiss does not explicitly teach, but Frank teaches determine an access level of the additional user device based on the additional user’s identity and an address associated with the additional user device (Frank [0113], e.g., The user identification may be a user's email address…… a unique hardware identifier of a user's client device, IP address of a user's client device; [0120], e.g., access to the group is limited to users that have been selected by the group administrator or super administrator. The authorized users can be indicated by a global identifier or user identification).
The motivation to combine is the same as that of claim 1.
Regarding claim 8, Weiss teaches a computer program product for data accessibility and management in a distributed network, the computer program product comprising a non-transitory computer-readable medium comprising code (Weiss [0154-0155], e.g., The mass storage device 612 and its associated computer-readable media provide non-volatile storage for the computer architecture 600…… Communication media includes computer readable instructions).
Regarding claim 10, the claim recites a computer program product of the system of claim 3, and is similarly analyzed.
Regarding claim 11, the claim recites a computer program product of the system of claim 4, and is similarly analyzed.
Regarding claim 15, the claim recites a method of the system of claim 1, and is similarly analyzed.
Regarding claim 17, the claim recites a method of the system of claim 3, and is similarly analyzed.
Regarding claim 18, the claim recites a method of the system of claim 4, an is similarly analyzed.
Claim(s) 5-6, 12-13, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Weiss in view of Frank, and in further view of U.S. Patent Publication 20240005277 A1 to Demmer et al. (Demmer).
Regarding claim 5, most of the limitations of this claim have been noted in the rejection of claim 4. Weiss and Frank do not explicitly teach, but Demmer teaches wherein the additional user is associated with the entity (Demmer [0075], e.g., the workspaces can be associated with a same organization; [0132], e.g., the user interface element 404 can include an input mechanism to enable a user to identify a third user to add (or remove) from the shared workspace…… the third user may be a member of the first workspace (e.g., Workspace B), the second workspace (e.g., Workspace 2), a workspace different than the first workspace and the second workspace, and/or a guest channel not associated with a workspace).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the combined teachings of Weiss and Frank with the teachings of Demmer with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of creating and managing shared workspaces via a streamlined and efficient process (Demmer [0157], e.g., As described above, techniques described herein enable users to create and manage shared workspaces via a streamlined and efficient process. Therefore, these techniques provide for a faster “conversion” process (i.e., “converting” a workspace communication to a new shared workspace communication). Furthermore, techniques described herein provide user accounts with similar control regarding the functionality of the workspace, allowing users of both workspaces the ability to manage aspects of the workspace. As such, the techniques described herein provide improvements to existing computing processes by streamlining the creation of new, shared workspaces).
Regarding claim 6, most of the limitations of this claim have been noted in the rejection of claim 4. Weiss and Frank do not explicitly teach, but Demmer teaches wherein the additional user comprises a third party user wherein the third party user is not associated with the entity (Demmer [0025], e.g., In some examples, members of a group, and thus workspace, can be associated with different organizations (e.g., entities with different organization identifiers); [0132], e.g., the user interface element 404 can include an input mechanism to enable a user to identify a third user to add (or remove) from the shared workspace…… the third user may be a member of the first workspace (e.g., Workspace B), the second workspace (e.g., Workspace 2), a workspace different than the first workspace and the second workspace, and/or a guest channel not associated with a workspace; Also see [0056], [0075]).
The motivation to combine is the same as that of claim 5.
Regarding claim 12, the claim recites a computer program product of the system of claim 5, and is similarly analyzed.
Regarding claim 13, the claim recites a computer program product of the system of claim 6, and is similarly analyzed.
Regarding claim 19, the claim recites a method of the system of claim 5, and is similarly analyzed.
Claim(s) 7, 14, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Weiss in view Frank, and in further view of Process Street. “How to Merge Channels in Slack.” Process Street | Checklist, Workflow and SOP Software | Checklist and Workflow Software for Businesses. Create Recurring Processes and Standard Operating Procedures in Seconds., 17 Apr. 2024 (Process Street).
Regarding claim 7, most of the limitations of this claim have been noted in the rejection of claim 1. Weiss and Frank do not explicitly teach, but Process Street teaches wherein the channel comprises a first channel (Process Street [Step 5], e.g., After initiating the merge process, designate the primary channel that will serve as the central hub for combined communication and collaboration), and wherein executing the instructions further causes the processing device to merge the first channel with a second channel (Process Street [Step 6], e.g., Following the selection of the primary channel, proceed to choose the secondary channel that will be merged with the primary one), wherein merging the first channel with the second channel comprises: generating a third channel, wherein the third channel combines the first channel and the second channel (Process Street [What Happens], e.g., Upon merging channels, all messages from the combined channels are aggregated into a single unified channel); authorizing first channel users, wherein the first channel users are users associated with the first channel (Process Street [What Happens], e.g., Following the merge, the members of the combined channels are unified); authorizing second channel users, wherein the second channel users are users associated with the second channel (Process Street [What Happens], e.g., Following the merge, the members of the combined channels are unified); and merging first channel input and second channel input, wherein the first channel input is input associated with the first channel, and wherein the second channel input is input associated with the second channel (Process Street [What Happens], e.g., Upon merging channels, all messages from the combined channels are aggregated into a single unified channel, consolidating communication and collaboration efforts within the workspace).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Weiss and Frank with the teachings of Process Street with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of enhancing collaboration and consolidating similar topics (Process Street [How to], e.g., Merging channels in Slack is a streamlined process that enhances team communication and organization by consolidating similar topics or teams within the workspace).
Regarding claim 14, the claim recites a computer program product of the system of claim 7, and is similarly analyzed.
Regarding claim 20, the claim recites a method of the system of claim 7, and is similarly analyzed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Slack. “Import Data from One Slack Workspace to Another.” Slack Help Center, 1 Apr. 2023, discloses importing a first workspace into a second workspace. Importing workspaces allows for channels from the first workspace to merge into the second workspace. Additionally, users from a first workspace would have access merged channels in the second workspace.
US 20220070013 A1 to Barzilay et al. discloses a system that allows users of a first group/channel to add users of a second group to form a combined channel. Users of the first group are able to import previous message data from the first channel into the combined channel.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE TRUONG whose telephone number is (571)272-6973. The examiner can normally be reached Monday - Friday, 8:00 am - 4 pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ali Shayanfar can be reached at (571) 270-1050. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/LAWRENCE TRUONG/Examiner, Art Unit 2434 /NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights