Prosecution Insights
Last updated: April 19, 2026
Application No. 18/385,599

HIERARCHICAL COLLABORATION PLANNING FEATURE INTEGRATION

Non-Final OA §102§103§112
Filed
Oct 31, 2023
Examiner
RIEGLER, PATRICK F
Art Unit
2171
Tech Center
2100 — Computer Architecture & Software
Assignee
Ncr Voyix Corporation
OA Round
1 (Non-Final)
55%
Grant Probability
Moderate
1-2
OA Rounds
4y 5m
To Grant
89%
With Interview

Examiner Intelligence

Grants 55% of resolved cases
55%
Career Allow Rate
189 granted / 346 resolved
At TC average
Strong +35% interview lift
Without
With
+34.6%
Interview Lift
resolved cases with interview
Typical timeline
4y 5m
Avg Prosecution
36 currently pending
Career history
382
Total Applications
across all art units

Statute-Specific Performance

§101
8.7%
-31.3% vs TC avg
§103
51.9%
+11.9% vs TC avg
§102
14.5%
-25.5% vs TC avg
§112
18.2%
-21.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 346 resolved cases

Office Action

§102 §103 §112
DETAILED ACTION This Non-Final communication 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 . Claims 1-20 have been examined. Drawings The drawings are objected to under 37 CFR 1.83(a) because they fail to show the graphical user interface for selecting a hierarchical meeting type within a collaboration client/service as described in the claims and specification. Any structural detail that is essential for a proper understanding of the disclosed invention should be shown in the drawing. MPEP § 608.02(d). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance. Claim Objections Claim 5 objected to because of the following informalities: it appears “…identifying, from the user input and for each of the two or more separate meetings, certain attendees, certain resources …” was intended. Claim 12 objected to because of the following informalities: it appears “…wherein obtaining further includes generating [[and]] metadata that identifies…” was intended. Appropriate correction is required. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. 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 specification purports the ability to access and modify any major well-known existing collaboration services such as Gmail®, Outlook®, Apple®, and Yahoo®, however, the specification does not convey how to have access to modify the existing collaboration services (i.e., how to incorporate plugin 114 with collaboration service 113, and/or how to add a UI component 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 to access and enhance any major well-known existing collaboration services to include a hierarchical meeting type for a meeting option within a user interface of a collaboration service. For similar reasons as above, “translating, by the plugin, the user input into two or more separate meetings 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 even the meeting “format” for that matter, is not described by the specification. Here, a similar leap is being made as above where the specification purports knowing the meeting 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, are 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 format the meetings for any major well-known existing collaboration services; in other words, translating, by the plugin, the user input into two or more separate meetings in a format recognized by the collaboration service. Dependent claims not mentioned inherit the deficiencies of their parent claims. 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. Claim(s) 1, 2, 10-14, 18, and 19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Wong et al. (US 2016/0247122 A1, hereinafter “Wong”). 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. More specifically, 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 for a browser (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]). 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; More specifically, several settings including the subject or appointment type for compound meeting, and attendees, times, attachments or places for sub-meetings can be set in the user interface (Wong, at least [0014]-[0017], Figures 3-5). translating, by the plugin, the user input into two or more separate meetings in a format recognized by the collaboration service; More specifically, 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]). Additionally, the email/calendaring server system 14 can translate the meeting times to the appropriate time zones for the invited individuals in different time zones depending, for example, on the configuration of the recipient's computer (time zone setting, daylight saving setting, etc.) (Wong, [0029]). providing, by the plugin, meeting details for the two or more separate meetings to the collaboration service in the format 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]). Regarding claim 2, Wong teaches 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 10, Wong teaches 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 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 teaches the method of claim 11, wherein obtaining further include generating and 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 teaches 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 teaches 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 (Wong, [0024]-[0027]). Regarding claim 18, Wong teaches 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; More specifically, 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 for a browser (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]). presenting a graphical user interface (GUI) to a meeting organizer when the 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. More specifically, several settings including the subject or appointment type for compound meeting, and attendees, times, attachments or places for sub-meetings can be set in the user interface (Wong, at least [0014]-[0017], Figures 3-5). translating the user input into separate meetings with separate meeting details in a format recognized by the collaboration client; More specifically, 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]). Additionally, the email/calendaring server system 14 can translate the meeting times to the appropriate time zones for the invited individuals in different time zones depending, for example, on the configuration of the recipient's computer (time zone setting, daylight saving setting, etc.) (Wong, [0029]). 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]). Claim Rejections - 35 USC § 103 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. Claim(s) 3-9, 15-17, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wong, and further in view of Bank et al. (US 2008/0294999 A1, hereinafter “Bank”). Regarding claim 3, Wong teaches 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 for 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 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 and Bank disclosing creating and providing meeting details to two or more calendars, and with Bank additionally disclosing that specific attendees can be given permissions to modify specific meeting options and 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 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]). Regarding claim 5, Wong teaches 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, …, 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). However, Wong may not explicitly teach every aspect of [identifying from the user input] certain attendee authorizations. 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 for 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 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 and Bank disclosing creating and providing meeting details to two or more calendars, and with Bank additionally disclosing that specific attendees can be given permissions to modify specific meeting options and 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 6, Wong and Bank 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 Bank 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]; Bank, at least [0031]-[0032]). Regarding claim 7, Wong and Bank 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]). Regarding claim 8, Wong and Bank 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]). Regarding claim 9, Wong and Bank teach the method of claim 8, wherein providing further includes providing each of the calendar data structures and each of the meeting messages 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]). Regarding claim 15, Wong teaches the method of claim 14, however, may not explicitly teach every aspect of 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. 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 for 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 Bank that a method for creating and providing meeting details to two or more calendars would include establishing attendee authorizations for each attendee that specify which meeting options can be modified by each attendee. With Wong and Bank disclosing creating and providing meeting details to two or more calendars, and with Bank additionally disclosing that specific attendees can be given permissions to modify specific meeting options, 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 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 16, Wong and Bank the method of claim 15, wherein obtaining further include generating second metadata for the attendee authorizations. More specifically, the combination of Wong and Bank 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]; Bank, at least [0031]-[0032]). Regarding claim 17, Wong and Bank 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 meetings to the collaboration client based on the user input including the first resources, the at least second resources, the indications, meeting criteria, and the attendees for the hierarchical meeting and the at least one sub meeting. More specifically, the combination of Wong and Bank 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]; Bank, at least [0031]-[0032]). 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 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 separated 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. 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 for 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 Bank that a method for creating and providing meeting details to two or more calendars would include establishing attendee authorizations for each attendee that specify which meeting options can be modified by each attendee. With Wong and Bank disclosing creating and providing meeting details to two or more calendars, and with Bank additionally disclosing that specific attendees can be given permissions to modify specific meeting options, 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 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. 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). 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 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
Read full office action

Prosecution Timeline

Oct 31, 2023
Application Filed
Mar 09, 2026
Non-Final Rejection — §102, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12547824
USER INTERFACE DATA ANALYZER HIGHLIGHTER
2y 5m to grant Granted Feb 10, 2026
Patent 12542869
Video Conference Apparatus, Video Conference Method and Computer Program Using a Spatial Virtual Reality Environment
2y 5m to grant Granted Feb 03, 2026
Patent 12535935
SYSTEMS AND METHODS FOR ANNOTATION PANELS
2y 5m to grant Granted Jan 27, 2026
Patent 12505140
AN INFORMATION INTERACTION VIA A MULTIMEDIA CONFERENCE
2y 5m to grant Granted Dec 23, 2025
Patent 12500984
NOTIFICATION SYSTEM NOTIFYING USER OF MESSAGE, CONTROL METHOD THEREFOR, AND STORAGE MEDIUM STORING CONTROL PROGRAM THEREFOR
2y 5m to grant Granted Dec 16, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

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

Prosecution Projections

1-2
Expected OA Rounds
55%
Grant Probability
89%
With Interview (+34.6%)
4y 5m
Median Time to Grant
Low
PTA Risk
Based on 346 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

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

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

Free tier: 3 strategy analyses per month