DETAILED ACTION
This FINAL action is in response to Application No. 18/385,599 filed 10/31/2023. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . The amendment presented on 6/18/2026 which provides amendment to claims 1, 5, 9-12, 17, 19, and 20 is hereby acknowledged. Claims 1-20 are currently pending.
Drawings and Specification
The amendment to the Replacement Drawings and Specification received 6/18/2026 are accepted and entered.
Claim Objections – Withdrawn
The previous claim objection(s) of claims 5 and 12 are withdrawn as necessitated by amendment.
Response to Arguments
Applicant’s arguments with respect to the 35 USC § 112(a) rejection have been considered, however, they are unpersuasive.
Regarding the first basis, Applicant quotes the specification stating, "the existing collaboration tool is enhanced to include the new meeting type as an option within the user interface and further enhanced to initiate the plugin (i.e., self-contained set of collaboration features described herein) when the option is selected by the user.” According to this, existing collaboration tools such as Microsoft® Teams®, Gmail®, Outlook®, Apple® mail and calendar service, Yahoo® mail and calendar service ([0013]) are enhanced/modified with the new meeting type option (button or selection, used to initiate the plugin). However, the Examiner maintains that the general public does not have the access to the source code of these services (nor does the specification explain how access is obtained) to modify the user interfaces of, for example, Gmail®, in order to include such a button. Based on the disclosure of this application, one of ordinary skill in the art has no clear ability to enhance the user interfaces of these existing collaboration tools to add this hierarchical meeting type option/button and therefore would not be able to make and use the invention without undue experimentation. If the invention described the “hierarchical meeting type option” as provided by the plugin itself, rather than presented in the user interface of an existing collaboration service (in order to initiate said plugin), the invention would not be subject to an enablement rejection for the above basis.
Regarding the second basis, Applicant quotes the specification stating, “[p]lugin agent 124 parses the data structures to define calendar data structures supported and recognized by the collaboration client 123." The issue is not whether one of ordinary skill in the art understands that translation of user input into a “recognized format” is accomplished by creating and parsing the hierarchical meeting and sub meeting data structures into “calendar data structures” via the API. The issue is that the “calendar data structures/format”, that would be “recognized” by any of the above-mentioned existing collaboration services, is not defined by the specification. This is a massive step to enable one of ordinary skill in the art to enhance existing collaboration services with hierarchical meetings. “Parsing” does not define the “calendar data structures recognized by existing collaboration services”. Implementing a hierarchical meeting type that existing collaboration services are not configured for requires some explanation of how the format/structure of the hierarchical meeting is translated to a format/structure of a calendar data structure recognized by existing collaboration services.
The amendments to the claims required an updated consideration and search, resulting in new prior art cited below.
However, Applicant’s arguments with respect to Wong have been considered and are unpersuasive.
Applicant contends Wong does not disclose a collaboration service or collaboration client that is enhanced to include a hierarchical meeting type as an option within its user interface and to initiate a plugin when that type is selected. However, Wong discloses a system to create a compound meeting that is hierarchical with sub-meetings which results in sending out normal meeting invitations that are specific to the invitees. Wong may not describe their invention as an “enhancement to existing collaboration services”, however, the functionality of creating a hierarchical meeting type and translating the meeting into individualized meetings typically used by existing collaboration services (Gmail®, Outlook®, etc.) is disclosed : “A user of one of the client-computing devices 12, using the web-based application 17, can schedule—and send out individualized email invites for—a compound meeting, having a series of sub-meetings, where multiple people (or multiple groups of people) are scheduled for individual sub-meeting time slots in the compound meeting, through a single meeting set-up process (Wong, [0009]).” A user can select an electronic calendar file type template that is recognized by existing collaboration services, such as “.ics” (Wong, [0016]). “Each electronic invite can include a calendar file attachment (e.g., an .ics filed) (Wong, [0033]).” Therefore, while the term “translate” is not explicitly recited, Wong definitely translates the compound meeting into typical calendar invites structures (“.ics” files) that can be used by existing collaboration services like Gmail® and Outlook®, all of which can be implemented by plug-in (Wong, [0010]).
Additionally, while Wong does not describe the compound meeting as an “object” that is “parsed”, the start/stop times, locations, attachments, etc. for the individualized meeting invites are determined from the compound meeting, which has the implication of a “parsing” for creating said individualized meeting invites from the parameters of the compound meeting.
Applicant contends Wong discloses the ability to add attachments and specify per-invitee attachments, but this is not the same as defining meeting attributes on a hierarchical meeting object that govern resource sharing between a hierarchical meeting and sub meeting objects as data structures within a plugin architecture integrated into an existing collaboration service via an API. However, the Examiner maintains the language is broad enough that simply attaching files to the parent/compound meeting results in the files being shared among invitees and subsequently, sub-meetings, and attaching the files to individual invites results in the files not being shared among invites or across any meetings. The claim would need to specify, for example, that specific sub-meetings can be designated for a resource included in the hierarchical meeting in order to differentiate from Wong.
Therefore, Wong is maintained for the applicable limitations as shown below.
Claim Rejections - 35 USC § 112
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1-20 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 enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Regarding claim 1 (and similarly in claims 11 and 19), at least “initiating, by a collaboration service, a plugin based on a user selecting a hierarchical meeting type for a meeting option within a user interface of a collaboration service” does not appear enabled by the specification. Specifically, the specification states “[t]he existing collaboration tool is enhanced to include the new [hierarchical] meeting type as an option within the user interface (Specification, abstract, [0007]).” Further, “[c]ollaboration service 113 is an existing collaboration service enhanced to support plugin agent 114. In an embodiment, collaboration service 113 is an email and calendar service, such as Gmail®, Outlook®, Apple® mail and calendar service, Yahoo® mail and calendar service, etc. (Specification, [0013]).” The claims and specification assumes the ability to access and modify any major well-known existing collaboration service such as Gmail®, Outlook®, Apple®, and Yahoo®, to include a selection for hierarchical meeting type, before initiating the plugin, however, the specification does not convey how one of ordinary skill in the art can modify the existing collaboration services (i.e., how to add a UI component/selection for selecting hierarchical meeting type). Therefore, without undo experimentation, one of ordinary skill in the art is not enabled by the specification to make and/or use the claimed invention without a description of how a selection/button for hierarchical meeting type for a meeting option within a user interface of a collaboration service can be added to any major well-known existing collaboration services.
For similar reasons as above, “translating, by the plugin, the user input into two or more separate meetings by parsing the hierarchical meeting object and the one or more sub meeting objects to define calendar data structures in a format recognized by the collaboration service” also does not appear enabled by the specification. For claim 11, the “causing…” limitation is construed as including this “translating” step. The specification states “the hierarchical collaboration plugin integrator translates the user input into two or more separate meetings in a format recognized by the collaboration client or collaboration service (specification, [0034])”. However, the “translating”, or most importantly, the “format”, is not described by the specification. Here, a similar leap is being made as above where the specification assumes one of ordinary skill knows the “format” recognized by any existing collaboration service such as Gmail®, Outlook®, Apple®, and Yahoo®. While an application programing interface (API) is referenced as a way of interacting with collaboration services (specification, [0008], [0014], [0026], [0027], [0035]), the particulars of how the API can interact with any collaboration service, let alone translating user input into meeting formats, is not described. Therefore, without undo experimentation, one of ordinary skill in the art is not enabled by the specification to make and/or use the claimed invention without a description of how to translate the user input into format recognized by any major well-known existing collaboration services.
Dependent claims not mentioned inherit the deficiencies of their parent claims.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claim 1 (and similarly in claims 11 and 19), “wherein the collaboration service is enhanced to include the hierarchical meeting type as an option within the user interface and to initiate the plugin when the hierarchical meeting type is selected by the user, and wherein the plugin interacts with the collaboration service via an application programming interface (API)” is unclear. As alluded to in the 112(a) rejection above, it is unclear how the existing collaboration service (such as Gmail®, specification at [0013]) is enhanced to include the hierarchical meeting type as an option, when one of ordinary skill in the art does not have to ability to modify source code and user interface of Gmail®. Therefore, it is unclear whether the hierarchical meeting type option is supposed to be part of a user interface of the collaboration service or the plugin.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1, 2 and 5-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wong et al. (US 2016/0247122 A1, hereinafter “Wong”), and further in view of Collet et al. (US 2010/0088144 A1, hereinafter “Collet”).
Regarding claim 1, Wong teaches a method, comprising:
initiating, by a collaboration service, a plugin based on a user selecting a hierarchical meeting type for a meeting option within a user interface of a collaboration service, wherein the collaboration service is enhanced to include the hierarchical meeting type as an option within the user interface and to initiate the plugin when the hierarchical meeting type is selected by the user, and wherein the plugin interacts with the collaboration service via an application programming interface (API). More specifically, a user can schedule and send out individualized email invites for a compound (hierarchical) meeting, having a series of sub-meetings, where multiple people (or multiple groups of people) are scheduled for individual sub-meeting time slots in the compound meeting, through a single meeting set-up process. The system can use a plug-in that allows a browser to interface with the email/calendaring app via an API (Wong, [0010]). Clicking the “Schedule” tab 104 can cause a compound meeting scheduling window 110 to open in a new browser window, as shown in FIG. 3 (Wong, [0014]). Alternatively, selecting control 140 allows a user to switch to a view from Figure 3, where the meeting invitation can be sent using an available “send” button in the lower right near label 110 without setting sub-meetings, to a view of Figure 5, where sub-meetings can be set up, effectively toggling a hierarchical meeting type (Wong, [0017]-[0018]).
presenting, by the plugin, a graphical user interface (GUI), to the user; receiving, by the plugin through the GUI, user input to define a hierarchical meeting, wherein the hierarchical meeting includes a hierarchical meeting object and one or more sub meeting objects, and wherein the GUI permits the user to select, browse, search or enter meeting criteria, meeting resources, meeting attributes, …; More specifically, several settings including the subject or appointment type for compound meeting, and attendees (with a search box), times (attributes), attachments (resources) or places (attributes or resources) for sub-meetings can be set in the user interface (Wong, at least [0014]-[0017], Figures 3-5). The user interface of Figure depicting all the sub-meetings implies an overarching hierarchical meeting object that presents that user interface combined with sub meeting objects (Wong, Figure 5).
translating, by the plugin, the user input into two or more separate meetings by parsing the hierarchical meeting object and the one or more sub meeting objects to define calendar data structures in a format recognized by the collaboration service, wherein the calendar data structures are provided to the collaboration service via the API. More specifically, system interfaces with popular collaboration services such as Gmail, Outlook, and Yahoo! or other third-party calendaring applications (Wong, [0008], [0013]). The system translates the compound/hierarchical meetings into regular individualized meeting invitations using standard “.ics” or other suitable electronic calendar file type that the popular collaboration services can utilize (Wong, [0016], [0033]). Therefore, the process of generating and sending the sub-meeting invitations from the compound meeting settings GUI is construed as translating the input into separate meetings (Wong, at least [0022]-[0023]).
providing, by the plugin, meeting details for the two or more separate meetings to the collaboration service in the format via the API, causing the collaboration service to schedule the two or more separate meetings on two or more calendars associated with attendees of the two or more separate meetings. More specifically, the result of the invitee accepting the sub-meeting invitations will schedule the sub-meetings on their respective calendars (Wong, [0009], [0020], [0022], [0033]).
However, Wong may not explicitly teach every aspect of
[the GUI permits the user to select] attendee authorizations for the hierarchical meeting object and the one or more sub meeting objects.
Collet discloses a method of scheduling events (hierarchical meeting) includes receiving event data specifying one or more sessions (sub-meetings) for an event, an event duration that encompasses a plurality of time slots, a respective duration for each session, a respective start time for the event and zero or more of the sessions, and information describing a plurality of attendees (Collet, abstract). Event management server interfaces with popular calendaring services such as MSN, Outlook, and Yahoo! using plug-ins (Collet, [0027]). The event management mechanism with an attribute acceptor allows users to set attributes for a hierarchical meeting with sub-meetings through a user interface (Collet, [0029], [0032]). An “add sub-meeting” button is construable to be a selection that toggles a hierarchical meeting (Collet, [0033]). A hierarchical meeting can have several levels such as “event” -> “group” -> “session”. Each of the meeting levels of the instantiated meeting are meeting object instances. A meeting object instance having an “event” meeting type value is a hierarchical meeting object, a meeting object instance having a “group” meeting type value is a subset of the sub-meetings, and a meeting object instance having a “session” meeting type value is a sub-meeting object. A “chair” person can be designated for each level of the hierarchical meeting which has control of only the levels equal to and below the chair (Collet, [0034]-[0036]). Meeting attributes include designated chairs, agendas, locations, invitees, optional vs mandatory attendance, etc. (Collet, [0031], [0034]). The meeting chair for a parent meeting object instance can also specify whether each attribute for each child meeting object instance is modifiable or locked for meeting attendees (Collet, [0032], [0038]). Therefore, the event “chair” sets attendee authorizations for the entire hierarchical meeting and group or session “chair” persons set attendee authorizations for the hierarchical meeting, at their designated level, and the levels below their designated level.
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention given the teachings of Wong and Collet that a method for creating a hierarchical meeting would include setting attendee authorizations for the hierarchical meeting object and the one or more sub meeting objects. With Wong and Collet disclosing creating hierarchical meetings, and with Collet additionally disclosing a “chair” person organizing the hierarchical meeting sets attendee authorizations for the hierarchical meeting object and the one or more sub-meeting objects, one of ordinary skill in the art of implementing a method for creating a hierarchical meeting would include setting attendee authorizations for the hierarchical meeting object and the one or more sub meeting objects in order to allow the hierarchical meeting creator to have control over the attributes of a meeting with multiple levels of authority. One would therefore be motivated to combine these teachings as in doing so would create this method for creating a hierarchical meeting.
Regarding claim 2, Wong and Collet teach the method of claim 1 further comprising, initiating, by the collaboration service, the plugin when a meeting entry associated with at least one of the two or more separate meetings is selected for a modification from a corresponding calendar by a corresponding attendee. More specifically, the invitees can accept, tentatively accept, or reject (modify) the invite by clicking on the “Yes,” “Maybe,” or “No” buttons 210, 212, 214 respectively in the invite (Wong, [0022]).
Regarding claim 5, Wong and Collet teach the method of claim 1, wherein receiving further includes identifying from the user input and for each of the two or more separate meetings, certain attendees, certain resources, certain attendee authorizations, and certain meeting criteria. More specifically, several settings including the subject or appointment type for compound meeting, and attendees, times (criteria), attachments or places (resources) for sub-meetings can be set in the user interface (Wong, at least [0014]-[0017], Figures 3-5). Additionally, meeting attributes include designated chairs, agendas, locations, invitees, optional vs mandatory attendance, etc. (Collet, [0031], [0034]). The meeting chair for a parent meeting object instance can also specify whether each attribute for each child meeting object instance is modifiable or locked for meeting attendees (Collet, [0032], [0038]).
Regarding claim 6, Wong and Collet teach the method of claim 5, wherein identifying further includes generating metadata that identifies the hierarchical meeting type and the certain attendee authorizations. More specifically, the combination of Wong and Collet teach creating meeting invitation data (metadata) including sub-meetings (hierarchical meeting type) and permissions for modifying fields of the invitation (authorizations) (Wong, at least [0014]-[0017]; Collet, at least [0032], [0038]).
Regarding claim 7, Wong and Collet teach the method of claim 6, wherein translating further includes generating a separate calendar data structure in the format for a corresponding meeting entry for each of the two or more separate meetings with corresponding certain attendees, corresponding certain resources, corresponding metadata, and corresponding certain meeting criteria. More specifically, each sub-meeting invite (message) is individualized to the meeting start and stop times (criteria) and attachments (resources) for each recipient’s (attendee’s) calendar (Wong, abstract, [0022], [0029], separate calendared meetings are construed as separate calendar structures). Additionally, the system is able to work with multiple calendaring systems such a Gmail, Outlook.com, and Yahoo! Mail, for example (Wong, [0008], [0013], [0023]). See also Collet [0016] and [0033].
Regarding claim 8, Wong and Collet teach the method of claim 7, wherein translating further includes generating a separate meeting message in the format for each of the two or more separate meetings with the corresponding certain attendees, the corresponding certain resources, the corresponding metadata, and the corresponding certain meeting criteria. More specifically, each sub-meeting invite (message) is individualized to the meeting start and stop times (criteria) and attachments (resources) for each recipient’s (attendee’s) calendar (Wong, abstract, [0022], [0029], separate calendared meetings are construed as separate calendar structures). Additionally, the system is able to work with multiple calendaring systems such a Gmail, Outlook.com, and Yahoo! Mail, for example (Wong, [0008], [0013], [0023]). See also Collet at least [0051].
Regarding claim 9, Wong and Collet teach the method of claim 8, wherein providing further includes providing each of the calendar data structures and each meeting message to the collaboration service via an application programming interface. More specifically, the system can use a plug-in for a browser that interfaces with the messaging/calendaring system via an API (Wong, [0010]). See also Collet [0023]-[0027].
Regarding claim 10, Wong and Collet teach the method of claim 1, wherein providing further includes providing corresponding meeting details for each of the two or more separate meetings in the format to the collaboration service, wherein each of the corresponding meeting details include metadata identifying the hierarchical meeting type. More specifically, Wong teaches creating meeting invitation data (metadata) including sub-meetings (hierarchical meeting type) settings as shown above (Wong, at least [0014]-[0017]).
Regarding claim 11, this claim recites a method substantially performed by the method of claim 1, therefore, the same rationale of rejection is applicable.
Regarding claim 12, Wong and Collet teach the method of claim 11, wherein obtaining further includes generating metadata that identifies the hierarchical meeting type for the hierarchical meeting and the at least one sub meeting. More specifically, Wong teaches creating meeting invitation data (metadata) including sub-meetings (hierarchical meeting type) settings as shown above (Wong, at least [0014]-[0017]).
Regarding claim 13, Wong and Collet teach the method of claim 12, wherein obtaining further includes identifying from the user input, first resources associated with the hierarchical meeting and at least second resources associated with the at least one sub meeting. More specifically, several settings including the subject or appointment type for compound meeting, and attendees, times, attachments (resources) or places for sub-meetings can be set in the user interface (Wong, at least [0014]-[0017], Figures 3-5). Attachments (e.g., pdf files, word documents, spreadsheets, image files, etc.) (resources) can be designated for all sub-meetings or specific attachments can be designated for specific sub-meetings (Wong, [0024]-[0027]).
Regarding claim 14, Wong and Collet teach the method of claim 13, wherein obtaining further includes identifying from the user input, an indication for each of the first resources and for each of the at least second resources as to whether a corresponding resource is sharable or not sharable between the hierarchical meeting and the at least one sub meeting. More specifically, attachments (e.g., pdf files, word documents, spreadsheets, image files, etc.) (resources) can be designated for all sub-meetings or specific attachments can be designated for specific sub-meetings, attachments can be designated for specific invitees and not all invitees (Wong, [0024]-[0027]).
Regarding claim 15, Wong and Collet teach the method of claim 14, wherein obtaining further includes identifying from the user input, attendee authorizations for attendees associated with the hierarchical meeting and the at least one sub meeting. More specifically, several settings including the subject or appointment type for compound meeting, and attendees, times (criteria), attachments or places (resources) for sub-meetings can be set in the user interface (Wong, at least [0014]-[0017], Figures 3-5). Additionally, meeting attributes include designated chairs, agendas, locations, invitees, optional vs mandatory attendance, etc. (Collet, [0031], [0034]). The meeting chair for a parent meeting object instance can also specify whether each attribute for each child meeting object instance is modifiable or locked for meeting attendees (Collet, [0032], [0038]).
Regarding claim 16, Wong and Collet teach the method of claim 15, wherein obtaining further include generating second metadata for the attendee authorizations. More specifically, the combination of Wong and Collet teach creating meeting invitation data (metadata) including sub-meetings (hierarchical meeting type) and permissions for modifying fields of the invitation (authorizations) (Wong, at least [0014]-[0017]). Additionally, meeting attributes include designated chairs, agendas, locations, invitees, optional vs mandatory attendance, etc. (Collet, [0031], [0034]). The meeting chair for a parent meeting object instance can also specify whether each attribute for each child meeting object instance is modifiable or locked for meeting attendees (Collet, [0032], [0038]).
Regarding claim 17, Wong and Collet teach the method of claim 16, wherein causing further includes providing the metadata and the second metadata with meeting details for each of the at least two separate meetings to the collaboration client based on the user input including the first resources, the at least second resources, corresponding indications, meeting criteria, and the attendees for the hierarchical meeting and the at least one sub meeting. More specifically, the combination of Wong and Collet teach creating meeting invitation data (metadata) including sub-meetings (hierarchical meeting type) and permissions for modifying fields of the invitation (authorizations), and sending the invitations to attendees’ clients (Wong, at least [0014]-[0017]; Attachments (e.g., pdf files, word documents, spreadsheets, image files, etc.) (resources) can be designated for all sub-meetings or specific attachments can be designated for specific sub-meetings (Wong, [0024]-[0027]). Additionally, meeting attributes include designated chairs, agendas, locations, invitees, optional vs mandatory attendance, etc. (Collet, [0031], [0034]). The meeting chair for a parent meeting object instance can also specify whether each attribute for each child meeting object instance is modifiable or locked for meeting attendees (Collet, [0032], [0038]).
Regarding claim 18, Wong and Collet teach the method of claim 11 further comprising, processing the method as a plugin to the collaboration client. More specifically, the system can use a plug-in for a browser (Wong, [0010]).
Regarding claim 19, Wong teaches a system, comprising:
at least one server comprising a processor and a non-transitory computer-readable storage medium; the non-transitory computer-readable storage medium comprising executable instructions; and the executable instructions when executed by the processor cause the processor to perform operations comprising:
using an application programming interface (API) to interact with a collaboration client as a plugin to the collaboration client, wherein the collaboration client is enhanced to include a hierarchical meeting type as an option within a user interface of the collaboration client and to initiate the plugin via the API when the hierarchical meeting type is selected; More specifically, a user can schedule and send out individualized email invites for a compound (hierarchical) meeting, having a series of sub-meetings, where multiple people (or multiple groups of people) are scheduled for individual sub-meeting time slots in the compound meeting, through a single meeting set-up process. The system can use a plug-in that allows a browser to interface with the email/calendaring app via an API (Wong, [0010]). Clicking the “Schedule” tab 104 can cause a compound meeting scheduling window 110 to open in a new browser window, as shown in FIG. 3 (Wong, [0014]). Alternatively, selecting control 140 allows a user to switch to a view from Figure 3, where the meeting invitation can be sent using an available “send” button in the lower right near label 110 without setting sub-meetings, to a view of Figure 5, where sub-meetings can be set up, effectively toggling a hierarchical meeting type (Wong, [0017]-[0018]).
presenting a graphical user interface (GUI) to a meeting organizer when a user selects a hierarchical meeting type from a user interface of the collaboration client; obtaining, from the GUI, user input provided by the meeting organizer that defines a hierarchical meeting and at least one sub meeting within the hierarchical meeting, wherein the GUI permits the meeting organizer to select, browse, search, and/or enter meeting criteria, meeting resources, meeting attributes, …. More specifically, several settings including the subject or appointment type for compound meeting, and attendees (with a search box), times (attributes), attachments (resources) or places (attributes or resources) for sub-meetings can be set in the user interface (Wong, at least [0014]-[0017], Figures 3-5). The user interface of Figure depicting all the sub-meetings implies an overarching hierarchical meeting object that presents that user interface combined with sub meeting objects (Wong, Figure 5).
translating the user input into separate meetings with separate meeting details in a format recognized by the collaboration client, by parsing a hierarchical meeting object and sub meeting objects created from the user input to define calendar data structures in the format, wherein the calendar data structures are provided to the collaboration client via the API; More specifically, system interfaces with popular collaboration services such as Gmail, Outlook, and Yahoo! or other third-party calendaring applications (Wong, [0008], [0013]). The system translates the compound/hierarchical meetings into regular individualized meeting invitations using standard “.ics” or other suitable electronic calendar file type that the popular collaboration services can utilize (Wong, [0016], [0033]). Therefore, the process of generating and sending the sub-meeting invitations from the compound meeting settings GUI is construed as translating the input into separate meetings (Wong, at least [0022]-[0023]).
generating metadata that identifies the hierarchical meeting type and including the metadata with each of the separate meeting details; More specifically, Wong teaches creating meeting invitation data (metadata) including sub-meetings (hierarchical meeting type) settings as shown above (Wong, at least [0014]-[0017]).
providing each of the separate meeting details to the collaboration client causing the collaboration client to schedule the separate meetings and including the metadata with corresponding separate meeting details. More specifically, the result of the invitee accepting the sub-meeting invitations will schedule the sub-meetings on their respective calendars (Wong, [0009], [0020], [0022], [0033]).
However, Wong may not explicitly teach every aspect of
[the GUI permits the user to select] attendee authorizations for the hierarchical meeting object and the one or more sub meeting objects.
Collet discloses a method of scheduling events (hierarchical meeting) includes receiving event data specifying one or more sessions (sub-meetings) for an event, an event duration that encompasses a plurality of time slots, a respective duration for each session, a respective start time for the event and zero or more of the sessions, and information describing a plurality of attendees (Collet, abstract). Event management server interfaces with popular calendaring services such as MSN, Outlook, and Yahoo! using plug-ins (Collet, [0027]). The event management mechanism with an attribute acceptor allows users to set attributes for a hierarchical meeting with sub-meetings through a user interface (Collet, [0029], [0032]). An “add sub-meeting” button is construable to be a selection that toggles a hierarchical meeting (Collet, [0033]). A hierarchical meeting can have several levels such as “event” -> “group” -> “session”. Each of the meeting levels of the instantiated meeting are meeting object instances. A meeting object instance having an “event” meeting type value is a hierarchical meeting object, a meeting object instance having a “group” meeting type value is a subset of the sub-meetings, and a meeting object instance having a “session” meeting type value is a sub-meeting object. A “chair” person can be designated for each level of the hierarchical meeting which has control of only the levels equal to and below the chair (Collet, [0034]-[0036]). Meeting attributes include designated chairs, agendas, locations, invitees, optional vs mandatory attendance, etc. (Collet, [0031], [0034]). The meeting chair for a parent meeting object instance can also specify whether each attribute for each child meeting object instance is modifiable or locked for meeting attendees (Collet, [0032], [0038]). Therefore, the event “chair” sets attendee authorizations for the entire hierarchical meeting and group or session “chair” persons set attendee authorizations for the hierarchical meeting, at their designated level, and the levels below their designated level.
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention given the teachings of Wong and Collet that a system for creating a hierarchical meeting would include setting attendee authorizations for the hierarchical meeting object and the one or more sub meeting objects. With Wong and Collet disclosing creating hierarchical meetings, and with Collet additionally disclosing a “chair” person organizing the hierarchical meeting sets attendee authorizations for the hierarchical meeting object and the one or more sub-meeting objects, one of ordinary skill in the art of implementing a system for creating a hierarchical meeting would include setting attendee authorizations for the hierarchical meeting object and the one or more sub meeting objects in order to allow the hierarchical meeting creator to have control over the attributes of a meeting with multiple levels of authority. One would therefore be motivated to combine these teachings as in doing so would create this system for creating a hierarchical meeting.
Regarding claim 20, Wong teaches the system of claim 19, however, may not explicitly teach every aspect of the executable instructions associated with obtaining further includes identifying attendee authorizations from the user input associated with attendees and access rights of the attendees and further permitting, after each of the separate meetings are scheduled and via the GUI, a given attendee with given attendee authorizations to modify, cancel, or change one or more of the hierarchical meeting and the at least one sub meeting. More specifically, meeting attributes include designated chairs, agendas, locations, invitees, optional vs mandatory attendance, etc. (Collet, [0031], [0034]). The meeting chair for a parent meeting object instance can also specify whether each attribute for each child meeting object instance is modifiable or locked for meeting attendees. A “chair” person can be designated for each level of the hierarchical meeting which has control of only the levels equal to and below the chair (Collet, [0032], [0034]-[0036], [0038]).
Claim(s) 3 and 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wong and Collet, and further in view of Bank et al. (US 2008/0294999 A1, hereinafter “Bank”).
Regarding claim 3, Wong and Collet teach the method of claim 2, however, may not explicitly teach every aspect of further comprising, presenting, by the plugin, the GUI to the corresponding attendee, obtaining attendee authorizations from metadata associated with the meeting entry, and greying out certain options within the GUI that the corresponding attendee lacks a proper attendee authorization for making the modification.
Bank discloses meeting originators grant permission to update (i.e., add, change, and/or delete) a field or fields of a meeting invitation that corresponds to a calendar entry on an electronic calendar, enabling a meeting invitee to update a meeting invitation and to thereby communicate updates that can be reflected in the corresponding electronic calendar entries of other people who are invited to the meeting (Bank, abstract). A meeting originator can set permissions to edit fields of the meeting invitation for each invitee using a user interface such as that of Figure 5 (Bank, [0031]-[0032]). Fields that an invitee does not have permission to edit are shown with shading or graying in a received invitation (Bank, [0038]-[0041], Figure 8).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention given the teachings of Wong and Collet with Bank that a method for creating and providing meeting details to two or more calendars would include having attendee authorizations for each attendee that specify which meeting options can be modified by each attendee and presenting a GUI greying out the options the attendees are not authorized to modify. With Wong, Collet, and Bank disclosing creating and providing meeting details to two or more calendars, with Collet and Bank disclosing specific attendees can be given permissions to modify specific meeting options, and with Bank additionally disclosing graying out the options that the attendees are not permitted to modify, one of ordinary skill in the art of implementing a method for creating and providing meeting details to two or more calendars would include having attendee authorizations for each attendee that specify which meeting options can be modified by each attendee and presenting a GUI greying out the options the attendees are not authorized to modify in order to allow attendees, that need to make a change to certain fields of a meeting calendar, the ability to efficiently make said change without having to request permission for each change, increasing efficiency and being a less time consuming approach, which is beneficial for meetings with large numbers of invitees (Bank, [0018]). One would therefore be motivated to combine these teachings as in doing so would create this method for creating and providing meeting details to two or more calendars.
Regarding claim 4, Wong and Collet with Bank teach the method of claim 3 further comprising, receiving, via the GUI from the corresponding attendee, the modification for a certain option that the corresponding attendee is authorized to make based on the attendee authorizations, and providing, by the plugin, the modification for the meeting entry to the collaboration service causing the collaboration service to update the meeting entry on corresponding calendars of corresponding attendees associated with the meeting entry. More specifically, when permitted modification to meeting options by a meeting attendee occurs, the meeting invitation and calendar is updated for all attendees (Bank, at least [0043], [0046], [0048]). Additionally, a chair at a certain level of the hierarchical meeting can modify attributes of the meeting for their level and below (Collet, [0036]).
Pertinent Prior Art
The prior art made of record on form PTO-892 and not relied upon is considered pertinent to applicant's disclosure. Applicant is required under 37 C.F.R. § 1.111(c) to consider these references fully when responding to this action.
Bank (US 2008/0294482 A1) - user interface for setting up a meeting with sub-meetings (Figures 2-3), translation occurs such that meeting invitations are received for ordinary non-hierarchical meetings.
Chen (US 2009/0006161 A1) – user interface for setting up a meeting with sub-meetings (Figure 3).
Krishnappa (US 2016/0019506 A1) – during meeting creation, it is determined whether sub-meetings should be created based on organizational policies (steps 312, 314).
Collet (US 2010/0088144 A1) – scheduling sub-meetings.
Han (US 2012/0110475 A1) – scheduling sub-meetings.
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PATRICK F RIEGLER whose telephone number is (571)270-3625. The examiner can normally be reached M-F 9:30am-6:00pm, 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, Kieu Vu can be reached at (571) 272-4057. 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.
/PATRICK F RIEGLER/ Primary Examiner, Art Unit 2171
Prosecution Insights