DETAILED ACTION
The following is a FINAL office action upon examination of the application number 18/806078.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Claims 1-4, 6, 9, 13-15, 18, and 19 have been amended.
Claim 14 has been canceled.
Claim 21 is new.
Claims 1-13 and 15-21 are pending in the application and have been examined on the merits discussed below.
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 1-13 and 15-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
(Step 1) Claims 1-12 are directed to a non-transitory computer-readable medium, which is a manufacture, and this a statutory category of invention. Claims 13, 15-18, and 21 are directed to a method; thus these claims are directed to a process, which is one of the statutory categories of invention. Claims 19-20 are directed to a system comprising one or more processors; thus the system comprises a device or set of devices, and therefore, is directed to a machine which is a statutory category of invention.
(Step 2A) The claims recite an abstract idea instructing how to generate meeting proposals based on user input and generating a calendar entry, which is described by claim limitations reciting:
identify based upon one or more communications communication messages provided …, an indication of a meeting between a first user … and second user …, wherein the one or more communication messages are generated …;
in response to identifying the indication of the meeting from the one or more communication messages, determine, whether a meeting parameter is missing from the one or more communication messages;
in response to determining that the meeting parameter is missing from the one or more communication messages, …a recommendation to generate an … meeting proposal for the meeting;
receive, … input providing a response to the recommendation, the response to the recommendation indicating to generate the … meeting proposal; and
in response to receiving the … input, … input a plurality of options to be selected by the second user … for the missing meeting parameter;
generate a meeting proposal … comprising an indication of the plurality of options; and
provide the meeting proposal … for selection of one of the plurality of options …;
in response to determining that the meeting parameter is not missing from the one or more communication messages:
…a recommendation to generate an … calendar entry for the meeting;
receive a second … input providing a response to the recommendation to generate the … calendar entry for the meeting, indicating to generate the … calendar entry; and
in response to receiving the second … input, generate the … calendar entry in an … calendar application with meeting parameters extracted from the one or more communication messages.
The identified limitations in the claims describing generating meeting proposals based on user input and generating a calendar entry (i.e., the abstract idea) fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas, which covers managing interactions between people. Dependent claims 2, 3, and 11, recite limitations that further describe/narrow generating meeting proposals based on user input and generating a calendar entry (i.e., the abstract idea); therefore, these claims are also found to recite an abstract idea.
This judicial exception is not integrated into a practical application because additional elements such as the tangible, non-transitory, computer-readable medium, comprising computer-readable instructions; first electronic device; second electronic device; and communications application in claim 1; the processor; first electronic device; second electronic device; and communications application in claim 13; and the memory; one or more processors configured to: host a communications application; first electronic device; and second electronic device in claim 19, do not add a meaningful limitation to the abstract idea since these elements are only broadly applied to the abstract ideas at a high level of generality; thus, none of recited hardware offers a meaningful limitation beyond generally linking the abstract idea to a particular technological environment, in this case, implementation via a computer/processor.
Additional elements related to an electronic calendar meeting proposal; electronic calendar entry; electronic calendar application; and a meeting proposal data object do not provide an improvement; these additional elements are recited at a high level of generality and only generally link the abstract idea to a technological environment. Additional elements such as …communication messages provided between a first electronic device and a second electronic device, within the communications application…; …messages are generated via a first communications application graphical user interface (GUI) of the first electronic device, a second communications application GUI of the second electronic device, or both...; render, in the first communications application GUI…; receive, via the first communications application GUI, a GUI input…; … render, in the first communications application GUI, a meeting proposal generator GUI element, the meeting proposal generator GUI element comprising an affordance…; render in the first communications application GUI…; … receive a second GUI input…; and provide the meeting proposal data object to the second electronic device for selection of one of the plurality of options via the second communications application GUI of the second electronic device do not yield an improvement in the functioning of the computer itself, nor do they yield improvements to a technical field or technology; further, these additional elements only add insignificant extra-solution activities (data gathering/display). Similarly, additional elements in claims 4, 5, 6, 7, 8, 9, 10, 12, 15, 16, 17, 18, and 20, related to rendering…, transmitting…, and generating…GUI… do not provide and improvement and only add insignificant extra-solution activities. Additional elements in claim 21 related to using a natural language processing (NLP) model do not provide an improvement to the computer or technology; these additional elements are recited at a high level of generality and only generally link the abstract idea to a technological environment. Accordingly, these additional element do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
(Step 2B) The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to integration of the abstract idea into a practical application, the hardware additional elements amount to no more than mere instructions to apply the exception using a generic computer component (see Spec. [0023]). Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Additional elements related to an electronic calendar meeting proposal; electronic calendar entry; electronic calendar application; and a meeting proposal data object do not provide an improvement; these additional elements are recited at a high level of generality and only generally link the abstract idea to a technological environment. Additional elements such as …communication messages provided between a first electronic device and a second electronic device, within the communications application…; …messages are generated via a first communications application graphical user interface (GUI) of the first electronic device, a second communications application GUI of the second electronic device, or both...; render, in the first communications application GUI…; receive, via the first communications application GUI, a GUI input…; … render, in the first communications application GUI, a meeting proposal generator GUI element, the meeting proposal generator GUI element comprising an affordance…; render in the first communications application GUI…; … receive a second GUI input…; and provide the meeting proposal data object to the second electronic device for selection of one of the plurality of options via the second communications application GUI of the second electronic device do not yield an improvement in the functioning of the computer itself, nor do they yield improvements to a technical field or technology; further, these additional elements only add insignificant extra-solution activities (data gathering/display). Additional elements in claims 4, 5, 6, 7, 8, 9, 10, 12, 15, 16, 17, 18, and 20, related to rendering…, transmitting…, and generating…GUI… do not provide and improvement and only add insignificant extra-solution activities. With respect to data gathering limitations, the courts have recognized the use of computers to receive and transmit data as a well-understood, routine, and conventional, OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network). With respect to data display limitations, the courts have found the presentation of data to be a well-understood, routine, conventional activity, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93 (see MPEP 2106.05(d)). Additional elements in claim 21 related to using a natural language processing (NLP) model do not provide an improvement to the computer or technology; these additional elements are recited at a high level of generality and only generally link the abstract idea to a technological environment. In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology.
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) 1-13 and 15-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2023/0153923 (Bell); in view of US 2018/0089634 (Cannons).
As per claim 1, Bell teaches: a tangible, non-transitory, computer-readable medium, comprising computer-readable instructions that when executed by one or more processors of one or more computers, cause the one or more computers to: ([0021] … The scheduling server (100) is in communication with a registered user device (102) that may be, for example, a personal computer, a mobile device such as a smartphone or tablet computer, or another computing device having a processor, memory, network communication device, and other components as may be necessary to receive, transmit, analyze, modify, and store information).
determine, from one or more communication messages provided between a first electronic device and a second electronic device, an indication of a meeting between a first user of the first electronic device and second user of the second electronic device, wherein the one or more communication messages are generated via a first communications application graphical user interface (GUI) of the first electronic device, a second communications application GUI of the second electronic device, or both; ([0023] The scheduling server (100) and user device (102) may also be in communication with one or more other user devices (104). [0044] … As messages are sent by participants in a chat thread where the assistant is present, such as illustrated in FIGS. 2B, 2D, and elsewhere, the messages are received by the scheduling server (100) via the assistant (e.g., in the case of an SMS thread, received at a phone number associated with the assistant, wherein the scheduling server (100) is configured to receive the text content provided to the phone number). Received messages are analyzed (500) to identify any wake words that may trigger automated actions or other response from the assistant [0046] … As an example, the system may have the phrase “get together” as a pre-defined wake word that should be used to explicitly trigger automated scheduling features (e.g., “Let's get together soon!”). Where a message is received such as “Let's meet together soon!” the system may be configured to identify that as a fuzzy wake word with similar effect due to the similar meaning and context.)
in response to determining the indication of the meeting from the one or more communication messages, determine whether a meeting parameter is missing from the one or more communication messages; ([0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe, activity, location, or other characteristics of the desired get together. …To the extent that such details cannot be identified (604) with some confidence, the system may respond and prompt the parties for additional information…).
in response to determining that the meeting parameter is missing from the one or more communication messages, render in the first communications application GUI, a recommendation to generate an electronic meeting proposal for the meeting; ([0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe, activity, location, or other characteristics of the desired get together. …To the extent that such details cannot be identified (604) with some confidence, the system may respond and prompt the parties for additional information (e.g., “Did I understand that you want to meet for lunch next week in Cincinnati? (reply yes, or reply with a time frame, activity, or location you′d like to change to)) [0054] Based on the determined information, the system may then generate a list of potential candidates for meeting, where each candidate on the list includes a time and day, and may additionally include an activity, a location, a duration, or other characteristics of the get together.).
receive a GUI input providing a response to the recommendation, the response to the recommendation indicating to generate the electronic meeting proposal; and ([0054] Based on the determined information, the system may then generate a list of potential candidates for meeting, where each candidate on the list includes a time and day, and may additionally include an activity, a location, a duration, or other characteristics of the get together [0056] Once the list is generated (612), the system may begin to propose meeting times to the communication thread (e.g., such as illustrated in FIG. 2B), in the general order that they are scored or otherwise ranked. As additional messages are received after a proposal, the system will continue to analyze (500) the messages to determine if they are confirmation, refusals, or other requests related to the list (e.g., “focus on lunch”, “focus on Cincinnati”, “let's wait till July”).)
in response to receiving the GUI input, render in the first communications application GUI, a meeting proposal generator GUI element,… ([0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe, activity, location, or other characteristics of the desired get together. …To the extent that such details cannot be identified (604) with some confidence, the system may respond and prompt the parties for additional information… [0053] In order to identify potential times for the desired get together, the system may check (606) the actual schedules of one or more identified (602) users (e.g., the “bottom up” availability), check (608) the scheduling preferences for the identified (602) users (e.g., the “top down” scheduling preferences”), and may also check (610) general scheduling preferences and configurations for the users, as user specific settings may influence the proposed list of times [0054] … the system may then generate a list of potential candidates for meeting, where each candidate on the list includes a time and day, and may additionally include an activity, a location, a duration, or other characteristics of the get together. Determination of the duration of a proposed get together may be based on an identified (604) activity or an activity automatically proposed based on various configured user preferences (608, 610). As an example, where the identified (604) activity is golf, the system may be configured to search for a four-hour long block of availability when proposing meeting times. Each potential get together time may be scored based upon factors such as compliance with user scheduling preferences (608), general user preferences (610), sufficient duration for activity, and other factors. [0056] Once the list is generated (612), the system may begin to propose meeting times to the communication thread (e.g., such as illustrated in FIG. 2B), in the general order that they are scored or otherwise ranked. As additional messages are received after a proposal, the system will continue to analyze (500) the messages to determine if they are confirmation, refusals, or other requests related to the list (e.g., “focus on lunch”, “focus on Cincinnati”, “let's wait till July”)).
the meeting proposal generator GUI element comprising an affordance to input a plurality of options to be selected from by the second user via the second electronic device for the missing meeting parameter, ([0053] In order to identify potential times for the desired get together, the system may check (606) the actual schedules of one or more identified (602) users (e.g., the “bottom up” availability), check (608) the scheduling preferences for the identified (602) users (e.g., the “top down” scheduling preferences”), and may also check (610) general scheduling preferences and configurations for the users, as user specific settings may influence the proposed list of times [0054] … the system may then generate a list of potential candidates for meeting, where each candidate on the list includes a time and day, and may additionally include an activity, a location, a duration, or other characteristics of the get together. Determination of the duration of a proposed get together may be based on an identified (604) activity or an activity automatically proposed based on various configured user preferences (608, 610). As an example, where the identified (604) activity is golf, the system may be configured to search for a four-hour long block of availability when proposing meeting times…. [0056] Once the list is generated (612), the system may begin to propose meeting times to the communication thread... As additional messages are received after a proposal, the system will continue to analyze (500) the messages to determine if they are confirmation, refusals, or other requests related to the list … Where a sufficient number of acceptances are received (616), the system may confirm (618) the meeting with the responding attendees, which may include providing a response to the communication thread (e.g., such as illustrated in FIG. 2D); meeting options list is presented to multiple users through the communication thread (second user). [0023] The scheduling server (100) and user device (102) may also be in communication with one or more other user devices (104). [0060] … the system may also allow users to interact with the scheduling server (100) itself, as well as with other accounts or platforms they have linked to the system (e.g., the third party availability services (106)) via communication with the assistant via a communication thread or channel).
generate a meeting proposal … comprising an indication of the plurality of options; and provide the meeting proposal … to the second electronic device for selection of one of the plurality of options via the second communications application GUI of the second electronic device ([0054] … the system may then generate a list of potential candidates for meeting, where each candidate on the list includes a time and day, and may additionally include an activity, a location, a duration, or other characteristics of the get together. Determination of the duration of a proposed get together may be based on an identified (604) activity or an activity automatically proposed based on various configured user preferences (608, 610). As an example, where the identified (604) activity is golf, the system may be configured to search for a four-hour long block of availability when proposing meeting times…. [0056] Once the list is generated (612), the system may begin to propose meeting times to the communication thread... As additional messages are received after a proposal, the system will continue to analyze (500) the messages to determine if they are confirmation, refusals, or other requests related to the list … Where a sufficient number of acceptances are received (616), the system may confirm (618) the meeting with the responding attendees, which may include providing a response to the communication thread (e.g., such as illustrated in FIG. 2D); meeting options list is presented to multiple users through the communication thread (second user). [0023] The scheduling server (100) and user device (102) may also be in communication with one or more other user devices (104). [0060] … the system may also allow users to interact with the scheduling server (100) itself, as well as with other accounts or platforms they have linked to the system (e.g., the third party availability services (106)) via communication with the assistant via a communication thread or channel).
Although not explicitly taught by Bell, Cannons teaches: generate a meeting proposal data object comprising an indication of the plurality of options; and provide the meeting proposal data object to the second electronic device for selection of one of the plurality of options via the second communications application GUI of the second electronic device ([0018] … an email with the meeting request to the one or more attendees. When an attendee receives and opens the email, the attendee is presented with multiple proposed meeting times in the context of the attendee's calendar. In other words, the user interface within the meeting request is optimized to provide the user with a visual demonstration of the proposed meeting times, thus providing the attendee with the ability to quickly and visually identify whether any of the proposed meeting times conflict. Further, the user interface within the meeting request is optimized to provide functionality to receive responses from the attendees. More particularly, each attendee is able to indicate which, if any, of the proposed meeting times are accepted. [0020] …a server 120 to send a meeting request 130 to be received by an attendee computing device 140 via an attendee productivity client 145 [0028] …the meeting request 130 integrates functionality to receive the attendee's response to each of the multiple proposed meeting times. For example, the meeting request 130 may provide options for accepting or rejecting each of the proposed meeting times. [0029] … the method 200 proceeds to OPERATION 210, where the computing system sends the meeting request 130 to each of the one or more attendees. [0030] At OPERATION 212, the computing system receives responses from the one or more attendees).
It would have been obvious, before the effective filing date of the claimed invention, for one of ordinary skill in the art to have modified the teachings of Bell with the aforementioned teachings of Cannons with the motivation of optimizing the collection of meeting responses from attendees (Cannons [0018]). Further, one of ordinary skill in the art would have recognized that applying the teachings of Cannons to the system of Bell would have yielded predictable results and doing so would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the presentation of options to users.
As per claim 2, Bell teaches: receive, via the affordance, an indication of the missing meeting parameter; and generate a meeting proposal data object comprising the missing meeting parameter ([0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe, activity, location, or other characteristics of the desired get together. …To the extent that such details cannot be identified (604) with some confidence, the system may respond and prompt the parties for additional information (e.g., “Did I understand that you want to meet for lunch next week in Cincinnati? (reply yes, or reply with a time frame, activity, or location you′d like to change to))”).
As per claim 3, Bell teaches: extract from the one or more communication messages one or more non-missing meeting parameters; and provide the one or more non-missing meeting parameters in the generated meeting proposal data object ([0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe, activity, location, or other characteristics of the desired get together. As an example, words or phrases that the system may identify (604) as suggestive of a particular time frame might include “soon”, “tomorrow”, “next week”, “end of the month”, or others. Words or phrases that may be identified (604) as suggestive of a particular activity might include “lunch”, “coffee”, “dinner”, “swim”, “bike ride”, “run”, or others. Words or phrases that may be identified (604) as suggestive of a location might include “visit you”, “visit me”, “next time you are in town”, “next time I am in town”, or others. [0054] Based on the determined information, the system may then generate a list of potential candidates for meeting, where each candidate on the list includes a time and day, and may additionally include an activity, a location, a duration, or other characteristics of the get together).
As per claim 4 Bell teaches: render a meeting proposal data object icon representative of the meeting proposal data object in a message input affordance configured to enable users to input a communications message to transmit (See Fig. 2C, 2D [0029] In FIG. 2C, prior to sending the proposed time, SP has sent a message to CD individually confirming that the determined potential meeting time should be shared with the entire thread.)
As per claim 5, Bell teaches: receive an indication of an interaction with a message transmit affordance; and in response to the receiving the indication, transmit the meeting proposal data object to the other of the first electronic device or the second electronic device (See Fig. 2C, 2D [0028] …user CD is now in a multi-party SMS thread with several of their contacts [0029] In FIG. 2C, prior to sending the proposed time, SP has sent a message to CD individually confirming that the determined potential meeting time should be shared with the entire thread.)
As per claim 6, Bell teaches: wherein the missing meeting parameter comprises a meeting time, ([0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe, activity, location, or other characteristics of the desired get together. …To the extent that such details cannot be identified (604) with some confidence, the system may respond and prompt the parties for additional information (e.g., “Did I understand that you want to meet for lunch next week in Cincinnati? (reply yes, or reply with a time frame, activity, or location you′d like to change to))”).
the computer-readable medium comprising computer-readable instructions that when executed by the one or more processors of the one or more computers, cause the one or more computers to: generate a calendar view within the meeting proposal generator GUI element, the calendar view comprising a timeslot proposal affordance enabling selection of a plurality of timeslots to propose for the meeting ([0054] …As an example, where the identified (604) activity is golf, the system may be configured to search for a four-hour long block of availability when proposing meeting times. [0055] … TABLE 1 Exemplary list of potential meeting times [0056] …a user my refuse the proposed meeting and request additional meeting times).
As per claim 7, Bell teaches: query a local electronic calendar application for existing entries via a calendar interface communicatively coupling the local electronic calendar application and the meeting proposal generator GUI element; and render, in the calendar view, the existing entries ([0024] The scheduling server (100) may also be in communication with one or more third party availability interfaces (106) or services, which may include local or cloud based calendars (e.g., a user may have one or calendars for professional uses or personal uses), [0029] … SP may provide other information to CD individually, such as summaries of their confirmed meeting times, and response options to automatically cancel or reschedule those meeting times (e.g., an SMS response of “cancel 1” would automatically cancel the recently schedule meeting with AB). [Claim 41] …provide calendar information for at least one user of the plurality of users…).
As per claim 8, Bell teaches: identify, based at least in part on the one or more communication messages, a range of time that the meeting time will likely occur within; and render, in the calendar view, a default view comprising the range of time that the meeting time will likely occur within ([0052] …identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe [0024] The scheduling server (100) may also be in communication with one or more third party availability interfaces (106) or services, which may include local or cloud based calendars (e.g., a user may have one or calendars for professional uses or personal uses), [0029] … SP may provide other information to CD individually, such as summaries of their confirmed meeting times, and response options to automatically cancel or reschedule those meeting times (e.g., an SMS response of “cancel 1” would automatically cancel the recently schedule meeting with AB). [Claim 41] …provide calendar information for at least one user of the plurality of users…).
As per claim 9, Bell teaches: wherein the missing meeting parameter comprises a meeting location, ([0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe, activity, location, or other characteristics of the desired get together. …To the extent that such details cannot be identified (604) with some confidence, the system may respond and prompt the parties for additional information…)
the computer-readable medium comprising computer-readable instructions that when executed by the one or more processors of the one or more computers, cause the one or more computers to: generate a location view within the meeting proposal generator GUI element, the location view comprising a location proposal affordance enabling selection of one or more locations to propose for the meeting. ([0052] … (e.g., “Did I understand that you want to meet for lunch next week in Cincinnati? (reply yes, or reply with a time frame, activity, or location you′d like to change to)) [0054] …where each candidate on the list includes a time and day, and may additionally include an activity, a location).
As per claim 10, Bell teaches: identify, based at least in part on the one or more communication messages, a location range that the meeting location will likely occur within; and render, in the location view, a default view comprising the location range ([0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe, activity, location, …, the system may respond and prompt the parties for additional information (e.g., “Did I understand that you want to meet for lunch next week in Cincinnati?).
As per claim 11, Bell teaches: query a location provision service for a keyword associated with a meeting type; receive a list of locations associated with the keyword; and display, in the location view, selectable affordances for each of the locations, enabling the locations to be selected as meeting location proposals ([0032] …In response to CD's message mentioning “lunch nearby,” SP suggests a potential meeting place along with instructions for confirming or reserving a table. On the server side, the management server (100) has analyzed the message context and identified “lunch” and “nearby” as relating to the meeting. As a registered user, the management server (100) has access to CD's registered location (e.g., or real time location as determined by a GPS signal or other location service and provided via a native software application on CD's user device), and may also have access to CD's configured or historic preferences for lunch locations. Using this information, as well as information on restaurant locations and hours (e.g., as may be available via a third party map service or API), the management server (100) has identified a suitable lunch location to propose).
As per claim 12, Bell teaches: in response to determining that the meeting parameter is not missing from the one or more communication messages, render in the first communications application GUI, the second communications application GUI, or both, a recommendation to generate an electronic calendar entry for the meeting; receive a second GUI input providing a response to the recommendation to generate the electronic calendar entry for the meeting, indicating to generate the electronic calendar entry; and in response to receiving the second GUI input, generate the electronic calendar entry in an electronic calendar application with meeting parameters extracted from the one or more communication messages ([0028] …receiving an SMS from AB proposing to “get together soon,” SP determines a potential meeting time based on scheduling information and preferences previously provided by CD, and proposes this time to the thread with instructions for response. [0029] In FIG. 2C, prior to sending the proposed time, SP has sent a message to CD individually confirming that the determined potential meeting time should be shared with the entire thread [0030] In FIG. 2D, each of AB and CD have replied and accepted the proposed time, prompting SP to confirm the scheduled get together. As will be discussed in more detail below, a number of server side activities are associated with a confirmation, including updating any third party availability services to reflect the scheduled time and configuring the future transmission of reminders to the attendees.).
As per claim 13, Bell teaches: a computer-implemented method, comprising: identifying, via a processor, based upon one or more communications communication messages provided between a first electronic device and a second electronic device, an indication of a meeting between a first user of the first electronic device and second user of the second electronic device, wherein the one or more communications communication messages are generated via a first communications application graphical user interface (GUI) of the first electronic device, a second communications application GUI of the second electronic device, or both; ([0023] The scheduling server (100) and user device (102) may also be in communication with one or more other user devices (104). [0044] … As messages are sent by participants in a chat thread where the assistant is present, such as illustrated in FIGS. 2B, 2D, and elsewhere, the messages are received by the scheduling server (100) via the assistant (e.g., in the case of an SMS thread, received at a phone number associated with the assistant, wherein the scheduling server (100) is configured to receive the text content provided to the phone number). Received messages are analyzed (500) to identify any wake words that may trigger automated actions or other response from the assistant [0046] … As an example, the system may have the phrase “get together” as a pre-defined wake word that should be used to explicitly trigger automated scheduling features (e.g., “Let's get together soon!”). Where a message is received such as “Let's meet together soon!” the system may be configured to identify that as a fuzzy wake word with similar effect due to the similar meaning and context.)
in response to identifying the indication of the meeting from the one or more communication messages, determining, via the processor, whether a meeting parameter is missing from the one or more communication messages; ([0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe, activity, location, or other characteristics of the desired get together. …To the extent that such details cannot be identified (604) with some confidence, the system may respond and prompt the parties for additional information…).
in response to determining that the meeting parameter is missing from the one or more communication messages: rendering, via the processor, in the first communications application GUI, a recommendation to generate an electronic meeting proposal for the meeting; ([0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together, which may include information suggesting a timeframe, activity, location, or other characteristics of the desired get together. …To the extent that such details cannot be identified (604) with some confidence, the system may respond and prompt the parties for additional information (e.g., “Did I understand that you want to meet for lunch next week in Cincinnati? (reply yes, or reply with a time frame, activity, or location you′d like to change to)) [0054] Based on the determined information, the system may then generate a list of potential candidates for meeting, where each candidate on the list includes a time and day, and may additionally include an activity, a location, a duration, or other characteristics of the get together.).
receiving, via the first communications application GUI, a GUI input providing a response to the recommendation, the response to the recommendation indicating to generate the electronic meeting proposal; and ([0054] Based on the determined information, the system may then generate a list of potential candidates for meeting, where each candidate on the list includes a time and day, and may additionally include an activity, a location, a duration, or other characteristics of the get together [0056] Once the list is generated (612), the system may begin to propose meeting times to the communication thread (e.g., such as illustrated in FIG. 2B), in the general order that they are scored or otherwise ranked. As additional messages are received after a proposal, the system will continue to analyze (500) the messages to determine if they are confirmation, refusals, or other requests related to the list (e.g., “focus on lunch”, “focus on Cincinnati”, “let's wait till July”).)
in response to receiving the GUI input; rendering, in the first communications application GUI, a meeting proposal generator GUI element, the meeting proposal generator GUI element comprising an affordance to input a plurality of options to be selected from by the second user via the second electronic device for the missing meeting parameter; ([0053] In order to identify potential times for the desired get together, the system may check (606) the actual schedules of one or more identified (602) users (e.g., the “bottom up” availability), check (608) the scheduling preferences for the identified (602) users (e.g., the “top down” scheduling preferences”), and may also check (610) general scheduling preferences and configurations for the users, as user specific settings may influence the proposed list of times [0054] … the system may then generate a list of potential candidates for meeting, where each candidate on the list includes a time and day, and may additionally include an activity, a location, a duration, or other characteristics of the get together. Determination of the duration of a proposed get together may be based on an identified (604) activity or an activity automatically proposed based on various configured user preferences (608, 610). As an example, where the identified (604) activity is golf, the system may be configured to search for a four-hour long block of availability when proposing meeting times…. [0056] Once the list is generated (612), the system may begin to propose meeting times to the communication thread... As additional messages are received after a proposal, the system will continue to analyze (500) the messages to determine if they are confirmation, refusals, or other requests related to the list … Where a sufficient number of acceptances are received (616), the system may confirm (618) the meeting with the responding attendees, which may include providing a response to the communication thread (e.g., such as illustrated in FIG. 2D); meeting options list is presented to multiple users through the communication thread (second user). [0023] The scheduling server (100) and user device (102) may also be in communication with one or more other user devices (104). [0060] … the system may also allow users to interact with the scheduling server (100) itself, as well as with other accounts or platforms they have linked to the system (e.g., the third party availability services (106)) via communication with the assistant via a communication thread or channel).
July”)).
generating a meeting proposal … comprising an indication of the plurality of options; and providing the meeting proposal … to the second electronic device for selection of one of the plurality of options via the second communications application GUI of the second electronic device; ([0054] … the system may then generate a list of potential candidates for meeting, where each candidate on the list includes a time and day, and may additionally include an activity, a location, a duration, or other characteristics of the get together. Determination of the duration of a proposed get together may be based on an identified (604) activity or an activity automatically proposed based on various configured user preferences (608, 610). As an example, where the identified (604) activity is golf, the system may be configured to search for a four-hour long block of availability when proposing meeting times…. [0056] Once the list is generated (612), the system may begin to propose meeting times to the communication thread... As additional messages are received after a proposal, the system will continue to analyze (500) the messages to determine if they are confirmation, refusals, or other requests related to the list … Where a sufficient number of acceptances are received (616), the system may confirm (618) the meeting with the responding attendees, which may include providing a response to the communication thread (e.g., such as illustrated in FIG. 2D); meeting options list is presented to multiple users through the communication thread (second user). [0023] The scheduling server (100) and user device (102) may also be in communication with one or more other user devices (104). [0060] … the system may also allow users to interact with the scheduling server (100) itself, as well as with other accounts or platforms they have linked to the system (e.g., the third party availability services (106)) via communication with the assistant via a communication thread or channel).
in response to determining that the meeting parameter is not missing from the one or more communication messages: rendering in the first communications application GUI, a recommendation to generate an electronic calendar entry for the meeting; receiving a second GUI input providing a response to the recommendation to generate the electronic calendar entry for the meeting, indicating to generate the electronic calendar entry; and in response to receiving the second GUI input, generating the electronic calendar entry in an electronic calendar application with meeting parameters extracted from the one or more communication messages ([0028] …receiving an SMS from AB proposing to “get together soon,” SP determines a potential meeting time based on scheduling information and preferences previously provided by CD, and proposes this time to the thread with instructions for response. [0029] In FIG. 2C, prior to sending the proposed time, SP has sent a message to CD individually confirming that the determined potential meeting time should be shared with the entire thread [0030] In FIG. 2D, each of AB and CD have replied and accepted the proposed time, prompting SP to confirm the scheduled get together. As will be discussed in more detail below, a number of server side activities are associated with a confirmation, including updating any third party availability services to reflect the scheduled time and configuring the future transmission of reminders to the attendees [0052] The system may also perform further analysis of the triggering message, and in some implementations may also perform additional analysis (e.g., semantic or other language analysis) of preceding messages, in order to identify (604) additional details relating to the desired get together).
Although not explicitly taught by Bell, Cannons teaches: generating a meeting proposal data object comprising an indication of the plurality of options; and providing the meeting proposal data object to the second electronic device for selection of one of the plurality of options via the second communications application GUI of the second electronic device; ([0018] … an email with the meeting request to the one or more attendees. When an attendee receives and opens the email, the attendee is presented with multiple proposed meeting times in the context of the attendee's calendar. In other words, the user interface within the meeting request is optimized to provide the user with a visual demonstration of the proposed meeting times, thus providing the attendee with the ability to quickly and visually identify whether any of the proposed meeting times conflict. Further, the user interface within the meeting request is optimized to provide functionality to receive responses from the attendees. More particularly, each attendee is able to indicate which, if any, of the proposed meeting times are accepted. [0020] …a server 120 to send a meeting request 130 to be received by an attendee computing device 140 via an attendee productivity client 145 [0028] …the meeting request 130 integrates functionality to receive the attendee's response to each of the multiple proposed meeting times. For example, the meeting request 130 may provide options for accepting or rejecting each of the proposed meeting times. [0029] … the method 200 proceeds to OPERATION 210, where the computing system sends the meeting request 130 to each of the one or more attendees. [0030] At OPERATION 212, the computing system receives responses from the one or more attendees).
It would have been obvious, before the effective filing date of the claimed invention, for one of ordinary skill in the art to have modified the teachings of Bell with the aforementioned teachings of Cannons with the motivation of optimizing the collection of meeting responses from attendees (Cannons [0018]). Further, one of ordinary skill in the art would have recognized that applying the teachings of Cannons to the system of Bell would have yielded predictable results and doing so would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the presentation of options to users.
As per claim 14, this claim recites limitations substantially similar to those addressed by the rejection of claim 2, above; therefore, the same rejection applies.
As per claim 15, this claim recites limitations substantially similar to those addressed by the rejection of claims 3, 4, and 5, above; therefore, the same rejection applies.
As per claim 16, this claim recites limitations substantially similar to those addressed by the rejection of claims 6 and 7, above; therefore, the same rejection applies.
As per claim 17, this claim recites limitations substantially similar to those addressed by the rejection of claim 8, above; therefore, the same rejection applies.
As per claim 18, this claim recites limitations substantially similar to those addressed by the rejection of claims 9 and 11, above; therefore, the same rejection applies.
As per claim 19, this claim recites limitations substantially similar to those addressed by the rejection of claim 13, above; therefore, the same rejection applies.
As per claim 20, this claim recites limitations substantially similar to those addressed by the rejection of claims 2-5, above; therefore, the same rejection applies.
Response to Arguments
Applicant's arguments filed 12/23/2025 have been fully considered but they are not persuasive.
With respect to the rejection under 35 USC 101, Applicant argues that the claims are integrated into a practical application.
Examiner respectfully disagrees. Additional elements reciting provide the meeting proposal data object to the second electronic device for selection of one of the plurality of options via the second communications application GUI of the second electronic device do not yield an improvement in the functioning of the computer itself, nor do they yield improvements to a technical field or technology; further, these additional elements only add insignificant extra-solution activities (data gathering/display).
As explained by the Supreme Court, the addition of insignificant extra-solution activity does not amount to an inventive concept, particularly when the activity is well-understood or conventional. Parker v. Flook, 437 U.S. 584, 588-89, 198 USPQ 193, 196 (1978). In Flook, the Court reasoned that "[t]he notion that post-solution activity, no matter how conventional or obvious in itself, can transform an unpatentable principle into a patentable process exalts form over substance. A competent draftsman could attach some form of post-solution activity to almost any mathematical formula". 437 U.S. at 590; 198 USPQ at 197; Id. (holding that step of adjusting an alarm limit variable to a figure computed according to a mathematical formula was "post-solution activity"). See also Mayo Collaborative Servs. v. Prometheus Labs. Inc., 566 U.S. 66, 79, 101 USPQ2d 1961, 1968 (2012) (additional element of measuring metabolites of a drug administered to a patient was insignificant extra-solution activity).
With respect to the rejection under 35 USC 101, Applicant argues that the claims are analogous to eligible claim 1 of Example 37.
Examiner respectfully disagrees. The additional elements in claim 37 recite a specific manner of automatically displaying icons to the user based on usage which provided a specific improvement to interfaces for electronic devices; in contrast, additional elements in the present claims related to GUI for presenting options and receiving input do not yield an improvement and only add insignificant extra-solution activities.
With respect to the rejection under 35 USC 102, Applicant argues that the art of record does not disclose the claimed features.
Examiner respectfully disagrees. The Applicant’s arguments are directed to newly amended features; additional search has been conducted and the rejection has been updated to address said amendments. See updated Claim Rejections - 35 USC § 103 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20230401539 (Chandra) – discloses the presentation of meeting recommendations to groups of users.
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 ALAN TORRICO-LOPEZ whose telephone number is (571)272-3247. The examiner can normally be reached M-F 10AM-5PM.
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, Beth Boswell can be reached at (571)272-6737. 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.
/ALAN TORRICO-LOPEZ/ Primary Examiner, Art Unit 3625