DETAILED ACTION
Response to Amendment
This Final office action is in response to Applicant’s amendment filed 3/26/2026. Claims 1, 2, 4, 6, 13 and 19 have been amended. Claims 1-20 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Applicant's arguments filed 3/26/2026 have been fully considered but they are not persuasive.
Regarding the previously pending 35 USC 101 rejection, claims 1-18 as a whole, recite additional elements that integrate the judicial exception into a practical application, under Prong Two of Step 2A of the Alice analysis.
Specifically, amended independent claim 1 recites, inter alia, “receiving a calendar event invite for a virtual meeting at a client device associated with a user, wherein the calendar event invite includes a calendar event object having a set of meeting sub-objects, including a meeting collaborative object and an attendance collection that identifies invitees and attendance status; and determining, by a processor, to provide an async participant option within the calendar event invite based on information included in the calendar event invite, the information including meeting details generated from the calendar event object and the set of meeting sub-objects, wherein determining to provide the async participant option within the calendar event invite causes a graphical user interface that displays the calendar event invite on the client device to display a new selectable element for the async participant option.”
Amended independent claim 13 recites, inter alia, “receiving a calendar event invite based on receiving the calendar event invite for a virtual meeting at a client device associated with a user within a first application, wherein the calendar event invite includes a calendar event object having a set of meeting sub-objects, including a meeting collaborative object and an attendance collection that identifies invitees and attendance status; and determining to provide an async participant option within the calendar event invite based on information included in the calendar event invite, the information including meeting details generated from the calendar event object and the set of meeting sub-objects.”
Drawings
The drawings were received on 3/26/2026 are accepted.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 19 and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims are directed to an abstract idea without significantly more.
Here, under step 1 of the Alice analysis, method claims 19 and 20 are directed to a series of steps. Thus the claims are directed to a process.
Under step 2A Prong One of the analysis, the claimed invention is directed to an abstract idea without significantly more. The claims recite implementing asynchronous user participation, including determining, detecting, providing, modifying, notifying, generating, receiving, and enabling steps.
The limitations of determining, detecting, providing, modifying, notifying, generating, receiving, and enabling, are a process that, under its broadest reasonable interpretation, covers organizing human activity concepts, but for the recitation of generic computer components.
Specifically, independent claim 19 elements recite generating, a calendar event invite for a virtual meeting that includes at least three participants, wherein the calendar event invite includes a calendar event object having a set of meeting sub-objects, including a meeting collaborative object and an attendance collection that identifies invitees and attendance status; receiving, from a participant of the at least three participants, a reply to the calendar event invite indicating the participant as an async participant, wherein the second client device determined to provide an async participant option within the calendar event invite based on information included in the calendar event invite; modifying an organizer calendar event for the virtual meeting based on updating the calendar event object at the first client device, which causes the organizer calendar event to indicate the participant as an async participant; and based on the organizer calendar event indicating the participant as an async participant: providing an indication for one or more actions to occur during the virtual meeting; and enabling display within the virtual meeting, the participant as an async participant that has access to meeting resources but that is not attending the virtual meeting.
That is, other than reciting a first and second client device, and the claim limitations merely cover managing personal behavior or interactions between people, thus falling within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claims recite an abstract idea.
Under Step 2A Prong Two, the eligibility analysis evaluates whether the claim as a whole integrates the recited judicial exception into a practical application of the exception. This judicial exception is not integrated into a practical application. The claims include a first and second client device. The first and second client device in the steps is recited at a high-level of generality, such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. As a result, the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of a first and second client device amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
None of the dependent claims recite additional limitations that are sufficient to amount to significantly more than the abstract idea. Claim 20 recites additional starting and providing steps. A more detailed abstract idea remains an abstract idea.
Under step 2B of the analysis, the claims include, inter alia, a client device, a processing system and a computer memory.
As discussed with respect to Step 2A Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in 2B, i.e., mere instructions to apply an exception on a generic computer cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
There isn’t any improvement to another technology or technical field, or the functioning of the computer itself. Moreover, individually, there are not any meaningful limitations beyond generally linking the abstract idea to a particular technological environment, i.e., implementation via a computer system. Further, taken as a combination, the limitations add nothing more than what is present when the limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
In addition, as discussed in paragraph 0130 of the specification, “The computer system 1000 includes a processing system including a processor 1001. The processor 1001 may be a general-purpose single- or multi-chip microprocessor (e.g., an Advanced Reduced Instruction Set Computer (RISC) Machine (ARM)), a special-purpose microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, etc. The processor 1001 may be referred to as a central processing unit (CPU) and may cause computer-implemented instructions to be performed. Although the processor 1001 shown is just a single processor in the computer system 1000 of FIG. 10, in an alternative configuration, a combination of processors (e.g., an ARM and DSP) could be used.”
As such, this disclosure supports the finding that no more than a general purpose computer, performing generic computer functions, is required by the claims.
Viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself. Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter. See Alice Corporation Pty. Ltd. v. CLS Bank Int’l et al., No. 13-298 (U.S. June 19, 2014).
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 6, 7, 9-16, 19 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Niess et al (US 20220368660 A1).
As per claim 1, Niess et al disclose a computer-implemented method for implementing asynchronous user participation across multiple computer applications (i.e., Techniques described herein enable users to “attend” or participate in an asynchronous meeting at any time or place that is convenient for them, using functionality available via a communication platform, ¶ 0020), comprising:
receiving a calendar event invite for a virtual meeting a client device associated with a user (i.e., the first user can tag one or more second users (e.g., meeting attendees) in the message. In some examples, such a tag can be an “invitation” to join an asynchronous meeting. In some examples, the first user can identify the one or more second users via an input to the message generation user interface. In some examples, the first user can tag a second user via a mention, a profile view, an email, or generating a link from the meeting generation interface that enables a second user to be added as an attendee of the asynchronous meeting, ¶ 0039, wherein scheduled asynchronous meetings can be generated via additional or alternative mechanisms, such as via a bot (e.g., based on detecting an intent to schedule a meeting, etc.), in association with a reminder, in association with a calendar appointment, ¶ 0049),
wherein the calendar event invite includes a calendar event object having a set of meeting sub-objects, including a meeting collaborative object and an attendance collection that identifies invitees and attendance status (i.e., asynchronous meetings, regardless of how they are scheduled, can be associated with an object that is stored in the datastore 122. Such an object can be a meeting object, which can be associated with a meeting identifier. In at least one example, the message object can be associated with a meeting identifier, one or more user identifiers (e.g., indicating the attendee(s) of the meeting), an originating user identifier (e.g., indicating the message originator), one or more invitee user identifier(s), ¶ 0068);
determining, by a processor, to provide an async participant option within the calendar event invite based on information included in the calendar event invite, the information including meeting details generated from the calendar event object and the set of meeting sub-objects (i.e., the message object can be associated with a r 15 meeting identifier, one or more user identifiers (e.g., indicating the attendee(s) of the asynchronous meeting), an originating user identifier (e.g., indicating the message originator), one or more invitee user identifier(s), identifier(s) of virtual space(s) to which the message is to be posted, ¶ 0050),
wherein determining to provide the async participant option within the calendar event invite causes a graphical user interface that displays the calendar event invite on the client device to display a new selectable element for the async participant option (i.e., the first user can tag a second user via a mention, a profile view, an email, or generating a link from the meeting generation interface that enables a second user to be added as an attendee of the asynchronous meeting, ¶ 0039);
in response to detecting a selection of the async participant option: providing a reply to the calendar event invite indicating the user as an async participant of the virtual meeting (i.e., the first user can tag a second user via a mention, a profile view, an email, or generating a link from the meeting generation interface that enables a second user to be added as an attendee of the asynchronous meeting, ¶ 0039); and
modifying a calendar event for the user displayed on the client device based on updating the calendar event object at the client device, which causes the calendar event to indicate async participation by the user in the virtual meeting, wherein the calendar event with the user as an async has different visual properties from other calendar events of the user (i.e., the meeting management component 116 can generate a meeting object based at least in part on the meeting details. In some examples, meetings, regardless of how they are scheduled, can be associated with an object that is stored in the datastore 122. Such an object can be a meeting object, which can be associated with a meeting identifier. In at least one example, based at least in part on receiving data input into the meeting generation user interface, the meeting management component 116 can receive such data and can generate a meeting object for the asynchronous meeting, ¶ 0151); and
after the virtual meeting occurs, notifying the client device when meeting resources created from the virtual meeting have been added to the calendar event displayed on the client device (i.e., content can be uploaded while it is being recorded or otherwise captured (or immediately after recording or otherwise capturing) such that a creator can post the content when the creator has finished recording or otherwise capturing the content. Content generated, uploaded, and/or otherwise provided can be posted as a reply to the message (e.g., representative of the asynchronous meeting), ¶ 0122).
As per claim 2, Niess et al disclose determining that the calendar event invite includes three or more meeting participants (i.e., the meeting generation user interface 226 can be a pop-up (as illustrated in FIG. 2B), overlay, or other user interface element presented via the user interface of the communication platform. In some examples, the meeting generation user interface 226 can take over the user interface 200 of the communication platform or comprise a new user interface, ¶ 0113 and Figure 2B); and enabling display of the async participant option within the calendar event invite in connection with a positive participant option and a negative participant option (i.e., FIG. 3A illustrates an instance of the user interface 200 as presented via a client of a user tagged as an attendee of the asynchronous meeting generated in FIG. 2B and/or another member of the virtual space (e.g., Channel D). As described above, in at least one example, the meeting management component 116 can cause a message associated with the asynchronous meeting, ¶ 0117).
As per claim 3, Niess et al disclose adding a prefix to a title of the calendar event indicating the async participant option (i.e., Meeting details can include a title and/or topic of the asynchronous meeting, ¶ 0037).
As per claim 4, Niess et al disclose modifying a visual appearance of the calendar event to a different color, transparency, or shade than the other non-async calendar events of the user from a same calendar (i.e., messages associated with asynchronous meetings can be associated with different presentation characteristics than messages that are not associated with asynchronous meetings such that they appear visually distinct from messages that are not associated with asynchronous meetings. For example, the user interface element 300 can be a different color, size, shape, etc. than other messages that are not associated with asynchronous meetings, ¶ 0117).
As per claim 6, Niess et al disclose determining that the calendar event invite includes an async participant flag positively indicating an availability of the async participant option (i.e., a user can post a message that is associated with an asynchronous meeting or the meeting management component 116 can post a message that is associated with an asynchronous meeting in a virtual space such as a channel, a direct message, a board, a virtual meeting hub, and/or the like. The message can be associated with one or more attendees. Meeting attendees can comprise users who are tagged in the message, ¶ 0086); and enabling display the async participant option within the calendar event invite in connection with a positive participant option and a negative participant option (i.e., FIG. 3A illustrates an instance of the user interface 200 as presented via a client of a user tagged as an attendee of the asynchronous meeting generated in FIG. 2B and/or another member of the virtual space (e.g., Channel D), ¶ 0117).
As per claim 7, Niess et al disclose generating a reply message that includes a selection of a positive participant option, a negative participant option, or a tentative participant option combined with an async participant flag (i.e., the notification can prompt each of the attendees to post a reply to the message. While the user interface element 306 is illustrated as a badge, in some examples, an attendee can be notified via a pop-up, a banner, or other user interface element presented via the user interface 200, ¶ 0120).
As per claim 9, Niess et al disclose wherein notifying the client device when the meeting resources created from the virtual meeting have been added to the calendar event is based on the user being an async participant of the virtual meeting (i.e., Content generated, uploaded, and/or otherwise provided can be posted as a reply to the message (e.g., representative of the asynchronous meeting), ¶ 0122).
As per claim 10, Niess et al disclose the meeting resources created from the virtual meeting that are added to the calendar event of the user include meeting notes, a meeting summary, or access to a meeting recording (i.e., content can be uploaded while it is being recorded or otherwise captured (or immediately after recording or otherwise capturing) such that a creator can post the content when the creator has finished recording or otherwise capturing the content. Content generated, uploaded, and/or otherwise provided can be posted as a reply to the message (e.g., representative of the asynchronous meeting), ¶ 0122).
As per claim 11, Niess et al disclose a calendar event object for the virtual meeting to be modified to indicate the user as an async participant, wherein multiple computer applications access the calendar event object to show the user as an async participant (i.e., the first user can tag a second user via a mention, a profile view, an email, or generating a link from the meeting generation interface that enables a second user to be added as an attendee of the asynchronous meeting, ¶ 0039, wherein the user computing device 104 can correspond to a “client” of a user. In some examples, the user computing device 104 can be associated with multiple “clients,” in which case, each instance of an application or other access point can be its own client. For example, a user can be signed into a first client (e.g., the application 140) and a second client (e.g., a web browser), both of which can be associated with the user computing device 104, ¶ 0082).
As per claim 12, Niess et al disclose detecting, before the virtual meeting, an additional selection of a positive participant option or a negative participant option within the calendar event; and removing modifications to the calendar event indicating the user as the async participant (i.e., As illustrated in FIG. 3A, a user interface element 300 can be presented via the user interface 200, for example, in association with the feed of Channel D. In at least one example, the message associated with the asynchronous meeting is viewable and/or interactable by each member of the virtual space (e.g., via instances of the user interface 200 presented via respective clients of the other members). In some examples, the message can be viewable and/or interactable by fewer than all members of the virtual space (e.g., users associated with a particular group, users tagged as attendees, etc.), ¶ 0117).
Claim 13 is rejected based upon the same rationale as the rejection of claim 1,
since it is the system claim corresponding to the method claim.
As per claim 14, Niess et al disclose the first application is a calendar application and the second application is a video-conferencing application (i.e., the virtual meeting hub may be organized by meeting type (e.g., asynchronous and synchronous). In some examples, the virtual meeting hub may also include a list of active users currently online and provide a user with a quick way to start a conversation with other active users whether it is via an audio, message, or video-based conversation, ¶ 0099).
As per claim 15, Niess et al disclose both the first application is a calendar application and the second application are a same video-conferencing application (i.e., the virtual meeting hub may be organized by meeting type (e.g., asynchronous and synchronous). In some examples, the virtual meeting hub may also include a list of active users currently online and provide a user with a quick way to start a conversation with other active users whether it is via an audio, message, or video-based conversation, ¶ 0099).
As per claim 16, Niess et al disclose providing the reply to the calendar event invite indicating the user as an async participant of the virtual meeting causes a calendar event object for the virtual meeting to be modified to indicate the user as an async participant, wherein a video-conference application prompts a participant attending the virtual meeting to perform one or more actions based on the calendar event object indicating the user as an async participant (i.e., the first user can tag a second user via a mention, a profile view, an email, or generating a link from the meeting generation interface that enables a second user to be added as an attendee of the asynchronous meeting, ¶ 0039, wherein the user computing device 104 can correspond to a “client” of a user. In some examples, the user computing device 104 can be associated with multiple “clients,” in which case, each instance of an application or other access point can be its own client. For example, a user can be signed into a first client (e.g., the application 140) and a second client (e.g., a web browser), both of which can be associated with the user computing device 104, ¶ 0082).
As per claim 19, Niess et al disclose a computer-implemented method for implementing asynchronous user participation across multiple computer applications (i.e., Techniques described herein enable users to “attend” or participate in an asynchronous meeting at any time or place that is convenient for them, using functionality available via a communication platform, ¶ 0020), comprising:
generating, at a first client device associated with a meeting organizer, a calendar event invite for a virtual meeting that includes at least three participants (i.e., the first user can tag one or more second users (e.g., meeting attendees) in the message. In some examples, such a tag can be an “invitation” to join an asynchronous meeting. In some examples, the first user can identify the one or more second users via an input to the message generation user interface. In some examples, the first user can tag a second user via a mention, a profile view, an email, or generating a link from the meeting generation interface that enables a second user to be added as an attendee of the asynchronous meeting, ¶ 0039, wherein scheduled asynchronous meetings can be generated via additional or alternative mechanisms, such as via a bot (e.g., based on detecting an intent to schedule a meeting, etc.), in association with a reminder, in association with a calendar appointment, ¶ 0049),
wherein the calendar event invite includes a calendar event object having a set of meeting sub-objects, including a meeting collaborative object and an attendance collection that identifies invitees and attendance status (i.e., asynchronous meetings, regardless of how they are scheduled, can be associated with an object that is stored in the datastore 122. Such an object can be a meeting object, which can be associated with a meeting identifier. In at least one example, the message object can be associated with a meeting identifier, one or more user identifiers (e.g., indicating the attendee(s) of the meeting), an originating user identifier (e.g., indicating the message originator), one or more invitee user identifier(s), ¶ 0068);
receiving, from a second client device associated with a participant of the at least three participants, a reply to the calendar event invite indicating the participant as an async participant (i.e., the first user can tag a second user via a mention, a profile view, an email, or generating a link from the meeting generation interface that enables a second user to be added as an attendee of the asynchronous meeting, ¶ 0039),
wherein the second client device determined to provide an async participant option within the calendar event invite based on information included in the calendar event invite (i.e., the message object can be associated with a r 15 meeting identifier, one or more user identifiers (e.g., indicating the attendee(s) of the asynchronous meeting), an originating user identifier (e.g., indicating the message originator), one or more invitee user identifier(s), identifier(s) of virtual space(s) to which the message is to be posted, ¶ 0050);
modifying an organizer calendar event for the virtual meeting displayed on the first client device based on updating the calendar event object at the first client device, which causes the organizer calendar event to indicate the participant as an async participant (i.e., the meeting management component 116 can generate a meeting object based at least in part on the meeting details. In some examples, meetings, regardless of how they are scheduled, can be associated with an object that is stored in the datastore 122. Such an object can be a meeting object, which can be associated with a meeting identifier. In at least one example, based at least in part on receiving data input into the meeting generation user interface, the meeting management component 116 can receive such data and can generate a meeting object for the asynchronous meeting, ¶ 0151); and
based on the organizer calendar event indicating the participant as an async participant: providing an indication to the first client device for one or more actions to occur during the virtual meeting (i.e., based at least in part on receiving an indication of an interaction with the affordance 224 (e.g., which can be associated with a request to generate and/or otherwise initiate an asynchronous meeting), the meeting management component 116 can cause a meeting generation user interface to be presented via the user interface of the communication platform, ¶ 0113); and
enabling display within the virtual meeting, the participant as an async participant that has access to meeting resources but that is not attending the virtual meeting (i.e., the virtual space can be a channel, a direct message, a board, a virtual meeting hub, and/or the like. In at least one example, the message associated with the asynchronous meeting is viewable by each member of the virtual space (e.g., each user permissioned to access the virtual space), ¶ 0041).
As per claim 20, Niess et al disclose starting a recording of the virtual meeting to be provided to one or more async participants; providing a first message for the virtual meeting to be recorded for the one or more async participants; or providing a second message for virtual meeting notes to be captured for the one or more async participants (i.e., content can be uploaded while it is being recorded or otherwise captured (or immediately after recording or otherwise capturing) such that a creator can post the content when the creator has finished recording or otherwise capturing the content. Content generated, uploaded, and/or otherwise provided can be posted as a reply to the message (e.g., representative of the asynchronous meeting), ¶ 0122).
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.
Claims 5, 8, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Niess et al (US 20220368660 A1), in view of Springer (US 20230030262 A1).
As per claim 5, Niess et al including the user as an async participant of the virtual meeting using a different indication than indications used to indicate an attending participant and a non-attending participant (i.e., a user can post a message that is associated with an asynchronous meeting or the meeting management component 116 can post a message that is associated with an asynchronous meeting in a virtual space such as a channel, a direct message, a board, a virtual meeting hub, and/or the like. The message can be associated with one or more attendees. Meeting attendees can comprise users who are tagged in the message, ¶ 0086); and setting a user status as available (i.e., a user interface element 300 can be presented via the user interface 200, for example, in association with the feed of Channel D. In at least one example, the message associated with the asynchronous meeting is viewable and/or interactable by each member of the virtual space (e.g., via instances of the user interface 200 presented via respective clients of the other members), ¶ 0117).
Niess et al does not disclose muting reminder notifications of the calendar event.
Springer discloses altering a notification may equate to different actions depending on different embodiments, situations, or contexts. In some embodiments, altering a notification may be performed by muting the notification or removing the notification (¶ 0058).
Niess et al and Springer are concerned with effective meeting and participant management. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include muting reminder notifications of the calendar event in Niess et al, as seen in Springer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 8, Niess et al disclose providing, at the client device, the user with access to communications from other meeting participants occurring during the virtual meeting (i.e., the virtual space can be a channel, a direct message, a board, a virtual meeting hub, and/or the like. In at least one example, the message associated with the asynchronous meeting is viewable by each member of the virtual space (e.g., each user permissioned to access the virtual space), ¶ 0041).
Niess et al does not disclose muting notifications at the client device of the communications from the other meeting participants occurring during the virtual meeting.
Springer discloses altering a notification may equate to different actions depending on different embodiments, situations, or contexts. In some embodiments, altering a notification may be performed by muting the notification or removing the notification (¶ 0058).
Niess et al and Springer are concerned with effective meeting and participant management. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include muting notifications at the client device of the communications from the other meeting participants occurring during the virtual meeting in Niess et al, as seen in Springer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim 17 is rejected based upon the same rationale as the rejection of claim 8, since it is the system claim corresponding to the method claim.
As per claim 18, Niess et al disclose providing the reply to the calendar event invite indicating the user as an async participant of the virtual meeting includes: indicating the user as a participant type supported by the third-party communication system; and automatically populating the reply to indicate that the user intends to join the virtual meeting as an async participant (i.e., the first user can tag a second user via a mention, a profile view, an email, or generating a link from the meeting generation interface that enables a second user to be added as an attendee of the asynchronous meeting, ¶ 0039).
Niess et al does not disclose the calendar event invite is provided by a third-party communication system that does not support async participants.
Springer discloses the calendar is external to the communication platform, and may be developed and/or maintained by a third party. In some embodiments, the communication platform integrates the calendar functionality into the platform, and/or connects to the calendar via a remote network or cloud solution (¶ 0042).
Niess et al and Springer are concerned with effective meeting and participant management. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the calendar event invite is provided by a third-party communication system that does not support async participants in Niess et al, as seen in Springer, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Response to Arguments
In the Remarks, Applicant argues, even assuming (without conceding) that the Office Action identifies an abstract idea, amended claim 1 integrates any such alleged abstract idea into a practical application by reciting a concrete, computer-implemented mechanism in which (i) a calendar event invite includes a calendar event object having meeting sub-objects (including a meeting collaborative object and an attendance collection), (ii) the async participant option is provided based on information included in the invite (including meeting details generated from the calendar event object/sub- objects), (iii) the calendar event object is used to determine when to activate the async participant option, and (iv) upon detecting the selection of the async participant option, the calendar event is modified based on updating the calendar event object (causing the calendar event to indicate async participation with different visual properties), followed by notifying the client device when meeting resources created from the virtual meeting have been added to the calendar event. In this way, independent claim 1, and the other currently amended independent claims, tie the user- facing option and downstream modifications to specific data structures and event-object updates rather than an abstract result. The Examiner respectfully disagrees.
Amended independent claim 19 merely recites “receiving, from a second client device associated with a participant of the at least three participants, a reply to the calendar event invite indicating the participant as an async participants wherein the second client device determined to provide an async participant option within the calendar event invite based on information included in the calendar event invite.”
Amended independent claim 19 fails to recite critical elements recited in amended independent claims 1 and 13, including “determining, by a processor, to provide an async participant option within the calendar event invite based on information included in the calendar event invite, the information including meeting details generated from the calendar event object and the set of meeting sub-objects.”
As a result, amended independent claim 19 fails to recite additional elements that integrate the judicial exception into a practical application, under Prong Two of Step 2A of the Alice analysis.
Applicant also argues Niess does not appear to disclose "receiving a calendar event invite based on receiving the calendar event invite for a virtual meeting at a client device associated with a user within a first application, wherein the calendar event invite includes a calendar event object having a set of meeting sub-objects, including a meeting collaborative object and an attendance collection that identifies invitees and attendance status," and "determining to provide an async participant option within the calendar event invite based on information included in the calendar event invite, the information including meeting details generated from the calendar event object and the set of meeting sub-objects," as recited by currently amended independent claim 1. Independent claims 13 and 17, while having different claim scopes, have been amended to include similar subject matter.
Furthermore, Niess does not disclose "determining to provide an async participant option within the calendar event invite based on information included in the calendar event invite, the information including meeting details generated from the calendar event object and the set of meeting sub-objects," as recited by currently amended independent claim 1. The Examiner respectfully disagrees.
As described in the updated rejection, and contrary to Applicant’s assertion, Niess et al indeed disclose Applicant’s amended claim language.
Conclusion
THIS ACTION IS MADE FINAL. 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ANDRE D BOYCE whose telephone number is (571)272-6726. The examiner can normally be reached M-F 10a-6:30p.
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, Rutao (Rob) Wu can be reached at (571) 272-6045. 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.
/ANDRE D BOYCE/Primary Examiner, Art Unit 3623 May 31, 2026
Prosecution Insights