Detailed Action
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 .
CLAIM INTERPRETATION
The following is a quotation of 35 U.S.C. 112(f):
(f) ELEMENT IN CLAIM FOR A COMBINATION.—An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“an input module configured to provide…”, “an event module configured to…”, “a timer module configured to…”, “a message creation module configured to…” and “a communication module configured to…”, in claim 1, “a notification module configured to…”, in claim 3, “event module is configured to…”, in claims 4, 5, 14 and 15, “a contact management module configured to…”, in claims 8 and 9, and “notification module and the communication module are configured to…”, in claim 10.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
A review of the specification shows that the following appears to be the corresponding structure described in the specification for the 35 U.S.C. 112(f) limitations“an input module configured to provide…”, “an event module configured to…”, “a timer module configured to…”, “a message creation module configured to…” and “a communication module configured to…”, in claim 1, “a notification module configured to…”, in claim 3, “event module is configured to…”, in claims 4, 5, 14 and 15, “a contact management module configured to…”, in claims 8 and 9, and “notification module and the communication module are configured to…”, in claim 10 (Figure 2, [0047]).
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
For more information, see MPEP § 2173 et seq. and Supplementary Examination Guidelines for Determining Compliance With 35 U.S.C. 112 and for Treatment of Related Issues in Patent Applications, 76 FR 7162, 7167 (Feb. 9, 2011).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 7, 11-12 and 17 are rejected under 35 U.S.C. 103(a) as being unpatentable over DiMaria et al. (US 2023/0291837 Al, hereinafter DiMaria), in view of KIM et al. (US 2016/0164559 Al, hereinafter Kim).
Regarding Claim 1, DiMaria discloses, a system for managing and responding to incoming calls (see e.g., “specifically to the field of integrating cloud-based callback management systems”, [0008] and/or “systems of the present invention may be implemented on a distributed computing network, such as one having any number of clients and/or servers”, Fig. 20, [0139]), comprising:
a first user device associated with a first user (see e.g., “system architecture 100 for a mobile device 101 connected to a callback cloud 110”, Fig. 1, [0059]);
a second user device associated with a second user (see e.g., “Clients 33 and servers 32 may communicate with one another via one or more electronic networks 31”, Fig. 20, [0139] and/or “providing a message to the caller requesting they call back…”, [0068]: Examiner’s note: caller with inherent calling device);
at least one database configured to store information related to the first user and the second user (see e.g., Fig. 2, database 34 and/or “Callback manager 113 may work with a user's profile as managed by a profile manager 111”, Fig. 1, [0061] and/or “, and
at least one server in communication with the first user device, the second user device, the database via a network, wherein the server comprises at least one memory for storing one or more program modules and at least one processor configured to execute the program modules (see e.g., “ Fig. 20, Servers 32, Clients 33, databases 34 and network 31, and/or “of servers 32 may be provided for handling requests received from one or more clients 33. Clients 33 and servers 32 may communicate with one another via one or more electronic networks 31”, Fig. 20, [0139] and /or “network server may be utilized to match a user identity or profile with an identifier, such as a phone number”, [0090]) wherein the modules comprise:
an input module configured to provide and enable selection of at least one mode to create at least one message (see e.g., “Input devices 28 may be of any type suitable for receiving user input”, Fig. 19, [0138] and/or “providing a callback selection on an incoming call prompt, the callback function may be exposed in other areas throughout the device's OS and applications”, [0070] and/or “the callback action is selected from the list of sending a text message, sending an email message, establishing a voice communication, and establishing a connection with a third-party server”, [0024]);
DiMaria fails to explicitly disclose, an event module configured to display one or more events and enable the first user to select at least one event that corresponds to a plan of the first user;
a timer module configured to enable the first user to define a duration of the selected event;
a message creation module configured to create the message comprising information related to the event and duration related to the event of the first user, wherein the message provides a reason of unavailability of the first user and the duration indicates a time duration that the second user needs to wait to contact the first user in real time, and
a communication module configured to automatically send the message to the second user device, when the first user receives a call from the second user during the predefined duration of the event.
In the same field of endeavor, Kim discloses an event module configured to display one or more events and enable the first user to select at least one event that corresponds to a plan of the first user (see e.g., “device 300-2 has determined that the user is on vacation based on schedule information of the user. When it is determined that the user is on vacation, the wearable device 300-2 may display a screen 1410”, Fig. 14, [0237] and/or “device 300-2 may store a plurality of strings including words related to types of schedules of the user…determine whether the user is working or is away based on types of schedules of the user. When it is determined that the user is away, the wearable device 300 may select and display a string 1402 including a text indicating that the user is away”, [0239] and/or “The wearable device 300 may display the selected at least one string in a message input window 1413 so that the user may edit the selected at least one string”, [0241]);
a timer module configured to enable the first user to define a duration of the selected event (see e.g., “device 300-2 may select at least one string corresponding to a starting time and an end time of a schedule of the user from among a plurality of strings…may select and display a string 1404 including a text indicating a starting time and an end time of vacation of the user based on schedule information of the user”, Fig. 14, [0240]);
a message creation module configured to create the message comprising information related to the event and duration related to the event of the first user, wherein the message provides a reason of unavailability of the first user and the duration indicates a time duration that the second user needs to wait to contact the first user in real time (see e.g., “device 300-2 may select at least one string corresponding to a starting time and an end time of a schedule of the user from among a plurality of strings…may select and display a string 1404 including a text indicating a starting time and an end time of vacation of the user based on schedule information of the user”, Fig. 14, [0240] and/or “device 300 may display the selected at least one string in a message input window 1413 so that the user may edit the selected at least one string”, [0241]; Examiner’s note: message 1413, “on vacation from Nov 3-Dec 5”, as exhibited in Fig. 14, indicates “on vacation” (i.e., reason of unavailability) and “Nov 3-Dec 5”, start/end of the event (i.e., duration indication to wait to contact the first user), and
a communication module configured to automatically send the message to the second user device, when the first user receives a call from the second user during the predefined duration of the event (see e.g., “ device 300-2 may transmit a message displayed in the message input window 1413 to the receiver device displayed in the receiver display window 1411 based on a user input for transmitting the message”, [0244] and/or “when a user input for writing a response message to an incoming call is received, the wearable device 300-2 may set a sender device that has made the call as a receiver device”, [0243] and/or “device 300-2 has determined that the user is on vacation based on schedule information of the user. When it is determined that the user is on vacation, the wearable device 300-2 may display a screen 1410”, Fig. 14, [0237]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria with Kim, in order to allow a user to easily transmit a message by providing a message that is predictive of a message intended by the user (please see Kim, paragraph [0002]).
Regarding Claim 2, DeMaria and Kim combined discloses, wherein the first user is a call recipient and the second user is a caller, and wherein the first user device and the second user device are a communication device (see DeMaria e.g., “incoming call 400 on a mobile device 101 with integrated callback features”, Fig. 4, [0067] and/or “system architecture 100 for a mobile device 101 connected to a callback cloud 110”, Fig. 1, [0059] and/or “Clients 33 and servers 32 may communicate with one another via one or more electronic networks 31”, Fig. 20, [0139] and/or “providing a message to the caller requesting they call back…”, [0068]: Examiner’s note: caller with inherent calling device).
Regarding Claim 7, DiMaria and Kim combined disclose, wherein the message comprises at least one of text, emoji, emoticons, graphics, audio, image, and video (see DiMaria e.g., “the callback action is selected from the list of sending a text message, sending an email message, establishing a voice communication, and establishing a connection with a third-party server”, [0024] and/or “or third-party entity can configure created callback triggers based on additional callback trigger criteria…a third-party callback trigger may be triggered… metadata associated with posted images or text”, [0112]).
Regarding Claim 11, DiMaria discloses, a method for managing and responding to incoming calls (see e.g., “specifically to the field of integrating cloud-based callback management systems”, [0008] and/or “systems of the present invention may be implemented on a distributed computing network, such as one having any number of clients and/or servers”, Fig. 20, [0139]), comprising the steps of:
providing a first user device associated with a first user (see e.g., “system architecture 100 for a mobile device 101 connected to a callback cloud 110”, Fig. 1, [0059]), a second user device associated with a second user (see e.g., “Clients 33 and servers 32 may communicate with one another via one or more electronic networks 31”, Fig. 20, [0139] and/or “providing a message to the caller requesting they call back…”, [0068]: Examiner’s note: caller with inherent calling device), at least one database for storing information related to the first user and the second user (see e.g., Fig. 2, database 34 and/or “Callback manager 113 may work with a user's profile as managed by a profile manager 111”, Fig. 1, [0061]), and at least one server in communication with the first user device, the second user device and the database via a network, wherein the server comprises at least one memory for storing one or more program modules and at least one processor configured to execute the program modules (see e.g., “ Fig. 20, Servers 32, Clients 33, databases 34 and network 31, and/or “of servers 32 may be provided for handling requests received from one or more clients 33. Clients 33 and servers 32 may communicate with one another via one or more electronic networks 31”, Fig. 20, [0139] and /or “network server may be utilized to match a user identity or profile with an identifier, such as a phone number”, [0090]);
providing, at the server via an input module, one or more modes to create the message and enabling selection of at least one mode to create at least one message (see e.g., “Input devices 28 may be of any type suitable for receiving user input”, Fig. 19, [0138] and/or “providing a callback selection on an incoming call prompt, the callback function may be exposed in other areas throughout the device's OS and applications”, [0070] and/or “the callback action is selected from the list of sending a text message, sending an email message, establishing a voice communication, and establishing a connection with a third-party server”, [0024]);
DiMaria fails to explicitly disclose, displaying, at the server via an event module, one or more events and enabling the first user to select at least one event that corresponds to a plan of the first user;
enabling, at the server via a timer module, the first user to define a duration of the selected event;
creating, at the server via a message creation module, message comprising information related to the event and duration related to the event of the first user, wherein the message provides a reason of unavailability of the first user and the duration indicates a time duration that the second user needs to wait to contact the first user in real time, and
automatically sending, at the server via a communication module, the message to the second user device, when the first user receives a Call from the second user during the predefined duration of the event.
In the same field of endeavor, Kim discloses displaying, at the server via an event module, one or more events and enabling the first user to select at least one event that corresponds to a plan of the first user (see e.g., “device 300-2 has determined that the user is on vacation based on schedule information of the user. When it is determined that the user is on vacation, the wearable device 300-2 may display a screen 1410”, Fig. 14, [0237] and/or “device 300-2 may store a plurality of strings including words related to types of schedules of the user…determine whether the user is working or is away based on types of schedules of the user. When it is determined that the user is away, the wearable device 300 may select and display a string 1402 including a text indicating that the user is away”, [0239] and/or “The wearable device 300 may display the selected at least one string in a message input window 1413 so that the user may edit the selected at least one string”, [0241]);
enabling, at the server via a timer module, the first user to define a duration of the selected event (see e.g., “device 300-2 may select at least one string corresponding to a starting time and an end time of a schedule of the user from among a plurality of strings…may select and display a string 1404 including a text indicating a starting time and an end time of vacation of the user based on schedule information of the user”, Fig. 14, [0240]);
creating, at the server via a message creation module, message comprising information related to the event and duration related to the event of the first user, wherein the message provides a reason of unavailability of the first user and the duration indicates a time duration that the second user needs to wait to contact the first user in real time (see e.g., “device 300-2 may select at least one string corresponding to a starting time and an end time of a schedule of the user from among a plurality of strings…may select and display a string 1404 including a text indicating a starting time and an end time of vacation of the user based on schedule information of the user”, Fig. 14, [0240] and/or “device 300 may display the selected at least one string in a message input window 1413 so that the user may edit the selected at least one string”, [0241]; Examiner’s note: message 1413, “on vacation from Nov 3-Dec 5”, as exhibited in Fig. 14, indicates “on vacation” (i.e., reason of unavailability) and “Nov 3-Dec 5”, start/end of the event (i.e., duration indication to wait to contact the first user), and
automatically sending, at the server via a communication module, the message to the second user device, when the first user receives a Call from the second user during the predefined duration of the event (see e.g., “ device 300-2 may transmit a message displayed in the message input window 1413 to the receiver device displayed in the receiver display window 1411 based on a user input for transmitting the message”, [0244] and/or “when a user input for writing a response message to an incoming call is received, the wearable device 300-2 may set a sender device that has made the call as a receiver device”, [0243] and/or “device 300-2 has determined that the user is on vacation based on schedule information of the user. When it is determined that the user is on vacation, the wearable device 300-2 may display a screen 1410”, Fig. 14, [0237]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria with Kim, in order to allow a user to easily transmit a message by providing a message that is predictive of a message intended by the user (please see Kim, paragraph [0002]).
Regarding Claim 12, DeMaria and Kim combined discloses, w wherein the first user is a call recipient and the second user is a caller, and wherein the first user device and the second user device are a communication device (see DeMaria e.g., “incoming call 400 on a mobile device 101 with integrated callback features”, Fig. 4, [0067] and/or “system architecture 100 for a mobile device 101 connected to a callback cloud 110”, Fig. 1, [0059] and/or “Clients 33 and servers 32 may communicate with one another via one or more electronic networks 31”, Fig. 20, [0139] and/or “providing a message to the caller requesting they call back…”, [0068]: Examiner’s note: caller with inherent calling device).
Regarding Claim 17, DiMaria and Kim combined disclose, wherein the message comprises at least one of text, emoji, emoticons, graphics, audio, image, and video (see DiMaria e.g., “the callback action is selected from the list of sending a text message, sending an email message, establishing a voice communication, and establishing a connection with a third-party server”, [0024] and/or “or third-party entity can configure created callback triggers based on additional callback trigger criteria…a third-party callback trigger may be triggered… metadata associated with posted images or text”, [0112]).
Claims 3-5, 10, 13-15 and 19-20 are rejected under 35 U.S.C. 103(a) as being unpatentable over DiMaria, in view of KIM, and further in view of Malhotra et al. (US 2016/0050315 Al, hereinafter Malhotra).
Regarding Claim 3, DiMaria and Kim combined fails to explicitly disclose, wherein the module further comprises a notification module configured to send notification to the second user on expiration of the predefined duration of the event of the first user, wherein the notification is a reminder indicating the availability of the first user to respond to calls.
In the same field of endeavor, Malhotra discloses, wherein the module further comprises a notification module configured to send notification to the second user on expiration of the predefined duration of the event of the first user, wherein the notification is a reminder indicating the availability of the first user to respond to calls (see e.g., “Responsive to user selection of a contact entry (e.g., indicating an intent of the caller to establish a phone call to the contact associated with that entry), a message 508 may be displayed. For example, responsive to selecting a contact with a driver status of “speeding” (e.g., as indicated by the speedometer icon), message 508 may present text indicating more information of the driver's (e.g., contact's) status and/or an indication of the driver's availability to answer a phone call at that time based on the driver's status.”, Fig. 5, [0053] and/or “last-known driver status received and/or determined at the in-vehicle computing system indicated that the driver is not available to take calls. Accordingly, the incoming call comprising the forwarded call to the driver 1212 is blocked at 1214… the mobile device of the calling party may receive the response to the calling party 1218 from the in-vehicle computing system and/or from the mobile device of the driver”, Fig. 12, [0072-0073] and/or “determine whether a change in driver status is detected. If at least one driver status indicator has changed (e.g., “YES” at 832), the method proceeds to 836 to indicate that the driver status has changed”, [0063] and/or “based on the driver status information, the calling party may decide whether to call the called party”, [0067]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Malhotra, in order to determine a called part status and presenting the driver status to a calling party, indicating a driver status to inform a calling party of the availability of a called party (e.g., a driver) (please see Malhotra, paragraphs [0003] and [0018]).
Regarding Claim 4, DiMaria and Kim combined fails to explicitly disclose, wherein the event module is configured to group the events in one or more categories.
In the same field of endeavor, Malhotra discloses, wherein the event module is configured to group the events in one or more categories (see e.g., “user interface 502 for a caller's mobile device 500 showing a contact list and associated driver statuses for users on the contact list. As illustrated, each entry in the contact list of the user interface 502 may include a driver identifier (e.g., a name/nickname), driver contact information (e.g., a phone number), and a driver status (e.g., an icon representing a current or last-known status of the driver).”, Fig. 5, [0052] and/or “At 714, method 700 includes determining if a change in driver status is detected. If a driver status change is not detected (e.g., “NO” at 714), the method returns to 704 to continue monitoring the vehicle status. If a driver status change is detected (e.g., “YES” at 714), the method proceeds to 716 to send an updated driver status to a server and/or caller device”, Fig. 7, [0056] and/or “Responsive to user selection of a contact entry (e.g., indicating an intent of the caller to establish a phone call to the contact associated with that entry), a message 508 may be displayed. For example, responsive to selecting a contact with a driver status of “speeding” (e.g., as indicated by the speedometer icon), message 508 may present text indicating more information of the driver's (e.g., contact's) status and/or an indication of the driver's availability to answer a phone call at that time based on the driver's status.”, Fig. 5, [0053]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Malhotra, in order to determine a called part status and presenting the driver status to a calling party, indicating a driver status to inform a calling party of the availability of a called party (e.g., a driver) (please see Malhotra, paragraphs [0003] and [0018]).
Regarding Claim 5, DiMaria and Kim combined fails to explicitly disclose, wherein the event module is configured to enable the first user to select at least one category to display the events grouped under the selected category.
In the same field of endeavor, Malhotra discloses, wherein the event module is configured to enable the first user to select at least one category to display the events grouped under the selected category (see e.g., “a driver may select the types of information provided to contacts at each privacy group and/or assign different contacts to different privacy groups. The user (e.g., the driver) may also provide a default privacy group for any caller that is not in the user's contact list. In some embodiments, a privacy group may not allow any information of the driver to be provided or simply an indication of the driver status (e.g., an icon) with no further information indicating the reason for that status. The information about the driver that is provided to a given caller (e.g., based on that caller's privacy group for the driver) may be available only in the driver status message or may be readily available (e.g., included in the contact list of that caller).”, Fig. 5, [0055]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Malhotra, in order to determine a called part status and presenting the driver status to a calling party, indicating a driver status to inform a calling party of the availability of a called party (e.g., a driver) (please see Malhotra, paragraphs [0003] and [0018]).
Regarding Claim 10, DiMaria and Kim combined fails to explicitly disclose, wherein the notification module and the communication module are configured to automatically send the message and send the notification to the assigned contacts, respectively.
In the same field of endeavor, Malhotra discloses, wherein the notification module and the communication module are configured to automatically send the message and send the notification to the assigned contacts, respectively (see e.g., “Responsive to user selection of a contact entry (e.g., indicating an intent of the caller to establish a phone call to the contact associated with that entry), a message 508 may be displayed. For example, responsive to selecting a contact with a driver status of “speeding” (e.g., as indicated by the speedometer icon), message 508 may present text indicating more information of the driver's (e.g., contact's) status and/or an indication of the driver's availability to answer a phone call at that time based on the driver's status.”, Fig. 5, [0053] and/or “Such an indication may be used at 714 of method 700 in FIG. 7 to determine whether a change in driver status is detected. If at least one driver status indicator has changed (e.g., “YES” at 832), the method proceeds to 836 to indicate that the driver status has changed. Again, the indication of a change in driver status may be used at 714 of FIG. 7 to determine whether a change in driver status is detected (e.g., to determine whether an update is to be sent to the server)”, [0063] and/or “based on the driver status information, the calling party may decide whether to call the called party. In the example described above, the driver status information may be provided to the calling party responsive to a relationship between a current time and/or location of the called party relative to a time/location of a calendar entry relevant to both the called party and the calling party. For example, the driver status information may be automatically provided to the calling party (e.g., as a notification, without the calling party attempting to call or view a contact entry associated with the called party). In this way, the calling party may be informed in the case that the called party is likely to be early or late to the event, and/or otherwise be reminded of the calendar entry.”, [0067]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Malhotra, in order to determine a called part status and presenting the driver status to a calling party, indicating a driver status to inform a calling party of the availability of a called party (e.g., a driver) (please see Malhotra, paragraphs [0003] and [0018]).
Regarding Claim 13, DiMaria and Kim combined fails to explicitly disclose, sending, at the server via a notification module, notification to the second user on expiration of the predefined duration of the event of the first user, wherein the notification is a reminder indicating the availability of the first user to respond to calls.
In the same field of endeavor, Malhotra discloses, sending, at the server via a notification module, notification to the second user on expiration of the predefined duration of the event of the first user, wherein the notification is a reminder indicating the availability of the first user to respond to calls (see e.g., “last-known driver status received and/or determined at the in-vehicle computing system indicated that the driver is not available to take calls. Accordingly, the incoming call comprising the forwarded call to the driver 1212 is blocked at 1214… the mobile device of the calling party may receive the response to the calling party 1218 from the in-vehicle computing system and/or from the mobile device of the driver”, Fig. 12, [0072-0073] and/or “determine whether a change in driver status is detected. If at least one driver status indicator has changed (e.g., “YES” at 832), the method proceeds to 836 to indicate that the driver status has changed”, [0063] and/or “based on the driver status information, the calling party may decide whether to call the called party”, [0067]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Malhotra, in order to determine a called part status and presenting the driver status to a calling party, indicating a driver status to inform a calling party of the availability of a called party (e.g., a driver) (please see Malhotra, paragraphs [0003] and [0018]).
Regarding Claim 14, DiMaria and Kim combined fails to explicitly disclose, wherein the event module is configured to group the events in one or more categories.
In the same field of endeavor, Malhotra discloses, wherein the event module is configured to group the events in one or more categories (see e.g., “user interface 502 for a caller's mobile device 500 showing a contact list and associated driver statuses for users on the contact list. As illustrated, each entry in the contact list of the user interface 502 may include a driver identifier (e.g., a name/nickname), driver contact information (e.g., a phone number), and a driver status (e.g., an icon representing a current or last-known status of the driver).”, Fig. 5, [0052] and/or “At 714, method 700 includes determining if a change in driver status is detected. If a driver status change is not detected (e.g., “NO” at 714), the method returns to 704 to continue monitoring the vehicle status. If a driver status change is detected (e.g., “YES” at 714), the method proceeds to 716 to send an updated driver status to a server and/or caller device”, Fig. 7, [0056]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Malhotra, in order to determine a called part status and presenting the driver status to a calling party, indicating a driver status to inform a calling party of the availability of a called party (e.g., a driver) (please see Malhotra, paragraphs [0003] and [0018]).
Regarding Claim 15, DiMaria and Kim combined fails to explicitly disclose, wherein the event module is configured to enable the first user to select at least one category to display the events grouped under the selected category.
In the same field of endeavor, Malhotra discloses, wherein the event module is configured to enable the first user to select at least one category to display the events grouped under the selected category (see e.g., “a driver may select the types of information provided to contacts at each privacy group and/or assign different contacts to different privacy groups. The user (e.g., the driver) may also provide a default privacy group for any caller that is not in the user's contact list. In some embodiments, a privacy group may not allow any information of the driver to be provided or simply an indication of the driver status (e.g., an icon) with no further information indicating the reason for that status. The information about the driver that is provided to a given caller (e.g., based on that caller's privacy group for the driver) may be available only in the driver status message or may be readily available (e.g., included in the contact list of that caller).”, Fig. 5, [0055]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Malhotra, in order to determine a called part status and presenting the driver status to a calling party, indicating a driver status to inform a calling party of the availability of a called party (e.g., a driver) (please see Malhotra, paragraphs [0003] and [0018]).
Regarding Claim 19, DiMaria and Kim combined fails to explicitly disclose, automatically sending, at the server via the communication module, to the second user device, if the first user receives a call from the second user during the predefined duration of the event and if the first user has assigned the second user as a contact to send the message.
In the same field of endeavor, Malhotra discloses, automatically sending, at the server via the communication module, to the second user device, if the first user receives a call from the second user during the predefined duration of the event and if the first user has assigned the second user as a contact to send the message (see e.g., “Responsive to user selection of a contact entry (e.g., indicating an intent of the caller to establish a phone call to the contact associated with that entry), a message 508 may be displayed. For example, responsive to selecting a contact with a driver status of “speeding” (e.g., as indicated by the speedometer icon), message 508 may present text indicating more information of the driver's (e.g., contact's) status and/or an indication of the driver's availability to answer a phone call at that time based on the driver's status.”, Fig. 5, [0053] and/or “Such an indication may be used at 714 of method 700 in FIG. 7 to determine whether a change in driver status is detected. If at least one driver status indicator has changed (e.g., “YES” at 832), the method proceeds to 836 to indicate that the driver status has changed. Again, the indication of a change in driver status may be used at 714 of FIG. 7 to determine whether a change in driver status is detected (e.g., to determine whether an update is to be sent to the server)”, [0063] and/or “based on the driver status information, the calling party may decide whether to call the called party. In the example described above, the driver status information may be provided to the calling party responsive to a relationship between a current time and/or location of the called party relative to a time/location of a calendar entry relevant to both the called party and the calling party. For example, the driver status information may be automatically provided to the calling party (e.g., as a notification, without the calling party attempting to call or view a contact entry associated with the called party). In this way, the calling party may be informed in the case that the called party is likely to be early or late to the event, and/or otherwise be reminded of the calendar entry.”, [0067]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Malhotra, in order to determine a called part status and presenting the driver status to a calling party, indicating a driver status to inform a calling party of the availability of a called party (e.g., a driver) (please see Malhotra, paragraphs [0003] and [0018]).
Regarding Claim 20, DiMaria and Kim combined fails to explicitly disclose, automatically sending, at the server via the communication module, the message to the assigned contacts, and
automatically sending, at the server via the notification module, the notification to the assigned contacts.
In the same field of endeavor, Malhotra discloses, automatically sending, at the server via the communication module, the message to the assigned contacts (see e.g., “Responsive to user selection of a contact entry (e.g., indicating an intent of the caller to establish a phone call to the contact associated with that entry), a message 508 may be displayed. For example, responsive to selecting a contact with a driver status of “speeding” (e.g., as indicated by the speedometer icon), message 508 may present text indicating more information of the driver's (e.g., contact's) status and/or an indication of the driver's availability to answer a phone call at that time based on the driver's status.”, Fig. 5, [0053] and/or “Such an indication may be used at 714 of method 700 in FIG. 7 to determine whether a change in driver status is detected. If at least one driver status indicator has changed (e.g., “YES” at 832), the method proceeds to 836 to indicate that the driver status has changed. Again, the indication of a change in driver status may be used at 714 of FIG. 7 to determine whether a change in driver status is detected (e.g., to determine whether an update is to be sent to the server)”, [0063]) and
automatically sending, at the server via the notification module, the notification to the assigned contacts (see e.g., “based on the driver status information, the calling party may decide whether to call the called party. In the example described above, the driver status information may be provided to the calling party responsive to a relationship between a current time and/or location of the called party relative to a time/location of a calendar entry relevant to both the called party and the calling party. For example, the driver status information may be automatically provided to the calling party (e.g., as a notification, without the calling party attempting to call or view a contact entry associated with the called party). In this way, the calling party may be informed in the case that the called party is likely to be early or late to the event, and/or otherwise be reminded of the calendar entry.”, [0067] and/or “Responsive to user selection of a contact entry (e.g., indicating an intent of the caller to establish a phone call to the contact associated with that entry), a message 508 may be displayed. For example, responsive to selecting a contact with a driver status of “speeding” (e.g., as indicated by the speedometer icon), message 508 may present text indicating more information of the driver's (e.g., contact's) status and/or an indication of the driver's availability to answer a phone call at that time based on the driver's status.”, Fig. 5, [0053]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Malhotra, in order to determine a called part status and presenting the driver status to a calling party, indicating a driver status to inform a calling party of the availability of a called party (e.g., a driver) (please see Malhotra, paragraphs [0003] and [0018]).
Claims 6 and 16 are rejected under 35 U.S.C. 103(a) as being unpatentable over DiMaria, in view of KIM, and further in view of Heikkinen et al. (US 2023/0108094 Al, hereinafter Heikkinen).
Regarding Claim 6, DiMaria and Kim combined disclose, wherein the modes of messages include an audio mode, a text mode and an image- based mode (see DiMaria e.g., “the callback action is selected from the list of sending a text message, sending an email message, establishing a voice communication, and establishing a connection with a third-party server”, [0024] and/or “or third-party entity can configure created callback triggers based on additional callback trigger criteria… In some implementations, a third-party callback trigger may be triggered… metadata associated with posted images or text”, [0112]).
DiMaria and Kim combined fails to explicitly disclose, wherein the modes of messages a video mode, a sticker-based mode.
In the same field of endeavor, Heikkinen discloses, wherein the modes of messages a video mode, a sticker-based mode (see e.g., “A collection of content (e.g., messages, including images, video, text, and audio) may be organized into an “event gallery” or an “event Story.””, [0028] and/or “interface with selectable stickers for sending in a message…”, [0077]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Heikkinen, in order to allow users to exchange content items (e.g., messages, images, video and/or stickers) with one another in a message thread (please see Heikkinen, paragraphs [0015]).
Regarding Claim 16, DiMaria and Kim combined disclose, wherein the modes of messages include an audio mode, a text mode and an image- based mode (see DiMaria e.g., “the callback action is selected from the list of sending a text message, sending an email message, establishing a voice communication, and establishing a connection with a third-party server”, [0024] and/or “or third-party entity can configure created callback triggers based on additional callback trigger criteria… In some implementations, a third-party callback trigger may be triggered… metadata associated with posted images or text”, [0112]).
DiMaria and Kim combined fails to explicitly disclose, wherein the modes of messages a video mode, a sticker-based mode.
In the same field of endeavor, Heikkinen discloses, wherein the modes of messages a video mode, a sticker-based mode (see e.g., “A collection of content (e.g., messages, including images, video, text, and audio) may be organized into an “event gallery” or an “event Story.””, [0028] and/or “interface with selectable stickers for sending in a message…”, [0077]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teachings of DiMaria and Kim with Heikkinen, in order to allow users to exchange content items (e.g., messages, images, video and/or stickers) with one another in a message thread (please see Heikkinen, paragraphs [0015]).
Claims 8-9 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over DiMaria, in view of KIM, and further in view of CZARNEKI et al. (US 2015/0312409 Al, hereinafter Czarneki).
Regarding Claim 8, DiMaria and Kim combined fails to explicitly disclose, wherein the module further comprises a contact management module configured to enable the first user to assign one or more contacts to at least one message, wherein the contact includes a phone number.
In the same filed of endeavor, Czarneki, wherein the module further comprises a contact management module configured to enable the first user to assign one or more contacts to at least one message, wherein the contact includes a phone number (see e.g., “message types may be selected for respective groups stored in a pho