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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Information Disclosure Statement
The IDS’s filed 9/10/2024 and 1/14/2025 have been considered. Examiner chose to focus on claim 18 as the starting placed for prior art rejections and used 2020/0310858 (Ren) to teach the independent claim. To avoid overly complicating prosecution, the prior art rejections of claims 24-30 were written using Ren as the primary reference. However, JPH08129527A (JP ‘527) disclosed in the IDS 1/14/2025, and included in the Chapter 1 International Preliminary Report is an excellent reference for claims 24-30, (see JP ‘527 [0009]). Even though Applicant filed a copy of this reference in the IDS dated 1/14/2025, Examiner has included the Espacenet translation of this reference in the prosecution history because the paragraph numberings are clearer. Please keep this reference, and the other prior art of record, in mind when making amendments and/or arguments to expedite prosecution.
Drawings
The drawings are objected to because:
In FIG. 3A, reference character 305 is used to label “calculator”, but another reference character 305 was included in the figure. This second “305” was likely included in error, and should be removed.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The disclosure is objected to because of the following informalities:
At Specification [0102]-[0104], reference character 601 and 602 appear to be swapped based on their corresponding figure, (See FIG. 6A(a)).
Appropriate correction is required.
Claim Objections
Claim 31 is objected to because of the following informalities:
In line 1 of claim 31, “An terminal device...” should read “A terminal device...”
Appropriate correction is required.
Claim Interpretation
In claims 22 and 35, Examiner considered the term “Android simulator” for indefiniteness. The term is further defined in the specification:
Currently, there are simulators of various brands in the market. For example, an Android simulator is a simulator that enables a user to run and simulate an Android operating system on a personal computer in addition to a native computer system, and can install, use, and uninstall Android application software. With the Android simulator, the user can use an Android application on an electronic device with the Android simulator even if the user does not have a mobile phone hardware device. For example, the Android simulator can simulate a running environment of an Android mobile phone on a computer, so that the user can experience Android games and applications on the computer.
(Specification [0003]).
As used in the claims and interpreted in light of the specification, the term is a specific operating system released on or before the effective filing date rather than a mark used by the company to identify a source of goods. Therefore, the term is not indefinite.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 36 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 36 contains the trademark/trade name “Huawei”. Where a trademark or trade name is used in a claim as a limitation to identify or describe a particular material or product, the claim does not comply with the requirements of 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph. See Ex parte Simpson, 218 USPQ 1020 (Bd. App. 1982). The claim scope is uncertain since the trademark or trade name cannot be used properly to identify any particular material or product. A trademark or trade name is used to identify a source of goods, and not the goods themselves. Thus, a trademark or trade name does not identify or describe the goods associated with the trademark or trade name. In the present case, the trademark/trade name is used to identify/describe a “video application” and, accordingly, the identification/description is indefinite.
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 24-30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to patent ineligible subject matter.
To determine if a claim is directed to patent ineligible subject matter, the Court has guided the Office to apply the Alice/Mayo test, which requires:
1. Determining if the claim falls within a statutory category;
2A. Determining if the claim is directed to a patent ineligible judicial exception consisting of a law of nature, a natural phenomenon, or abstract idea; and
2B. If the claim is directed to a judicial exception, determining if the claim recites limitations or elements that amount to significantly more than the judicial exception.
(See MPEP 2106).
Step 2A is a two-prong inquiry, (see MPEP 2106.04(II)(A)). Under the first prong, examiners evaluate whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Abstract ideas include mathematical concepts, certain methods of organizing human activity, and mental processes, (see MEPEP 2106.04(a)(2)). The second prong is an inquiry into whether the claim integrates a judicial exception into a practical application. MPEP 2106.04(d).
During examination, examiners should apply the same eligibility analysis to all claims regardless of the number of exceptions recited therein. Unless it is clear that a claim recites distinct exceptions, such as a law of nature and an abstract idea, care should be taken not to parse the claim into multiple exceptions, particularly in claims involving abstract ideas. Accordingly, if possible examiners should treat the claim for Prong Two and Step 2B purposes as containing a single judicial exception. See MPEP 2106.04(II)(B).
With respect to claim 24, applying step 1, the preamble of claim 24 claims a method so this claim falls within the statutory category of a process. In order to apply step 2A, a recitation of claim 24 is copied below. The limitations of the claim that describe an abstract idea are bolded.
A message reminding method, comprising:
receiving, by a simulator, a first message sent by a first application, wherein:
the first message comprises an identifier of a second application,
the second application is an application that receives a new message, and
the first application and the second application are applications in a system carried by the simulator;
determining, by the simulator, a corresponding second window identifier based on the identifier of the second application; and
determining, by the simulator based on the second window identifier and a window identifier of a mouse focus window, whether to perform reminding on the new message received by the second application.
Under step 2A prong one, the limitations “determining, by the simulator, a corresponding second window identifier based on the identifier of the second application; and determining, by the simulator based on the second window identifier and a window identifier of a mouse focus window, whether to perform reminding on the new message received by the second application.” have been determined by the courts to be mental processes because such language (i.e., defining, determining, processing, and analyzing) can practically be performed in the human mind. For example:
a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016)
An application program interface for extracting and processing information from a diversity of types of hard copy documents – Content Extraction, 776 F.3d at 1345, 113 USPQ2d at 1356.
(see MPEP 2106.04(a)(2)(III)).
Under step 2A prong two, the judicial exception has not been integrated into a practical application. Here, the claim recites one additional limitation: (1) receiving, by a simulator, a first message sent by a first application, wherein: the first message comprises an identifier of a second application, the second application is an application that receives a new message, and the first application and the second application are applications in a system carried by the simulator.
The only additional limitation falls within the category of insignificant extra-solution activity because this is mere data gathering. See MPEP 2106.04(d) referencing MPEP 2106.05(g), example (iv) - Obtaining information about transactions. As noted above, the limitations of defining… and determining... are mental processes. Similar to obtaining information about transactions in order to perform an abstract idea, merely receiving information as input in order to perform an abstract idea does not add a meaningful limitation to the abstract idea.
If the claim as a whole integrates the recited judicial exception into a practical application, then it would be patent eligible. Here, the claim is generally linked to simulator/emulator/virtualization technology for how notifications/reminders are handled by a simulated OS, (see Specification [0003]-[0004]), but the claim does not provide any specific details connecting the mental process to how the simulated OS uses the physical or virtual hardware to implement the determining steps. Stated at this level of generality and when the claim is considered as a whole, the determining steps may be performed entirely in the human mind.
Moving on to step 2B of the analysis, Examiner must consider whether each claim limitation individually or as an ordered combination amounts to significantly more than the abstract idea. This analysis includes determining whether an inventive concept is furnished by an element or a combination of elements that is beyond the judicial exceptions. For limitations that were categorized as “apply it” or generally linking the use of the abstract idea to a particular technological environment or field of use, the analysis is the same. The limitations that were determined to be extra-solution activity will require further analysis.
The only additional limitation “(1) receiving, by a simulator, a first message sent by a first application, wherein: the first message comprises an identifier of a second application, the second application is an application that receives a new message, and the first application and the second application are applications in a system carried by the simulator” is not significantly more because the courts have found similar limitations to not be significantly more, see MPEP 2106.05(d)(II) example (i) - Receiving or transmitting data over a network.
After reviewing the specification and looking at the claim as a whole, there is no indication that this claim is directed to a combination of known elements arranged or organized in an unconventional manner. As drafted and under a broadest reasonable interpretation, generic computer components may be arranged in the conventional manner to perform the claimed limitations. Therefore, looking at the claim as an ordered combination, the limitations do not amount to significantly more than the abstract idea.
For the foregoing reasons, claim 24 is rejected under 35 U.S.C. 101 as being directed to patent ineligible subject matter.
With respect to claim 25, the claimed invention is directed to an abstract idea without significantly more. The claim recites: wherein the first message is sent by the second application to the first application. This limitation is further defining the first message, which is part of the receiving limitation. The receiving limitation, including this additional limitation is not an abstract idea, but instead falls within the category of insignificant extra-solution activity because this is mere data gathering. See MPEP 2106.04(d) referencing MPEP 2106.05(g), example (iv) - Obtaining information about transactions. The receiving limitation, including this additional limitation is not significantly more because the courts have found similar limitations to not be significantly more, see MPEP 2106.05(d)(II) example (i) - Receiving or transmitting data over a network. For the foregoing reasons, claim 25 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 26, the claimed invention is directed to an abstract idea without significantly more. The claim recites: wherein the first message is sent by the second application to the first application through a third application. This limitation is further defining the first message, which is part of the receiving limitation. The receiving limitation, including this additional limitation is not an abstract idea, but instead falls within the category of insignificant extra-solution activity because this is mere data gathering. See MPEP 2106.04(d) referencing MPEP 2106.05(g), example (iv) - Obtaining information about transactions. The receiving limitation, including this additional limitation is not significantly more because the courts have found similar limitations to not be significantly more, see MPEP 2106.05(d)(II) example (i) - Receiving or transmitting data over a network. For the foregoing reasons, claim 26 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 27, the claimed invention is directed to an abstract idea without significantly more. The claim recites: wherein determining, by the simulator based on the second window identifier and the window identifier of the mouse focus window, whether to perform the reminding on the new message received by the second application comprises: when the simulator determines that the second window identifier is different from the window identifier of the mouse focus window, determining, by the simulator, to perform the reminding on the new message received by the second application. The limitation is further modifying the “determining...whether to perform reminding...” limitation of claim 24. In that context, placing further determining limitations on the determining limitation, does not change the mental process nature of the limitation. This judicial exception is not integrated into a practical application because there are no additional limitations outside of the abstract idea other than what has already been considered in claim 24. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the same reason. For the foregoing reasons, claim 27 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 28, the claimed invention is directed to an abstract idea without significantly more. The claim recites: when the simulator determines that the second window identifier is the same as the window identifier of the mouse focus window, determining, by the simulator, not to perform the reminding on the new message received by the second application. The limitation is further modifying the “determining...whether to perform reminding...” limitation of claim 24. In that context, placing further determining limitations on the determining limitation, does not change the mental process nature of the limitation. This judicial exception is not integrated into a practical application because there are no additional limitations outside of the abstract idea other than what has already been considered in claim 24. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the same reason. For the foregoing reasons, claim 28 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 29, the claimed invention is directed to an abstract idea without significantly more. The claim recites: wherein the first message further comprises: a quantity of new messages received by the second application; and content of the new message received by the second application. This limitation is further defining the first message, which is part of the receiving limitation. The receiving limitation, including this additional limitation is not an abstract idea, but instead falls within the category of insignificant extra-solution activity because this is mere data gathering. See MPEP 2106.04(d) referencing MPEP 2106.05(g), example (iv) - Obtaining information about transactions. The receiving limitation, including this additional limitation is not significantly more because the courts have found similar limitations to not be significantly more, see MPEP 2106.05(d)(II) example (i) - Receiving or transmitting data over a network. For the foregoing reasons, claim 29 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
With respect to claim 30, the claimed invention is directed to an abstract idea without significantly more. The claim recites: wherein: a reminding manner for performing the reminding on the new message received by the second application comprises at least one of: application icon flickering, application window flickering, a pop-up window, a notification, and application window shaking, and the pop-up window or the notification comprises a quantity of new messages or content of the new message. The limitation is modifying a part of the determining limitation “determining...whether to perform reminding...” limitation of claim 24. In that context, placing further limitations on the “manner” or object of the determining, does not change the mental process nature of the limitation. This judicial exception is not integrated into a practical application because there are no additional limitations outside of the abstract idea other than what has already been considered in claim 24. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the same reason. For the foregoing reasons, claim 30 is rejected under 35 U.S.C. 101, as being directed to patent ineligible subject matter.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 18-23 and 31-36 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 2020/0310858 A1 (Ren)
With respect to claim 18, Ren teaches A method, comprising (see FIGS. 5-8; with a primary focus on how OS-Notification calls work, [0071]-[0072], and the virtual desktop 601 of remote operating system 505 running on simulator/workspace environment 600, [0076]; note FIG. 7 and FIG. 8 show the method, but the OS notification call pathway is best shown in FIG. 5, and the end result is best shown in FIG. 6): receiving, by a first application, a first message sent by a second application, wherein (the second application, which is application 504, sends a notification by means of operating system-level notification interception 508 to the first application, which is the operating system 505, [0071] lines 1-6; in the context of FIG. 6, operating system 505 is a remote desktop, [0076] lines 1-3; from the user's point of view, 601 and 505 are a single application called a "virtual desktop", read the rest of [0076] and [0003]; notification is intercepted by interception layer 513, [0072] lines 1-2, but at least one embodiment has 513 combined with operating system 505, [0072] lines 14-15, so the notification is still received by the "first application"): the first message comprises an identifier of the second application (The unified application notification framework may determine an identifier (ID) for the received notification. The identifier may indicate the virtual application associated with the notification and/or the backend service. ... The identifier may be inserted into the notification by the sender ( e.g., application, notification interception layer, backend service, etc), [0088] lines 1-9; the embodiment that teaches this limitation is when the identifier is added by the application 504, see FIG. 5 showing the OS-level interception pathway), the second application is an application that receives a new message (For example, the backend service 511 may be a mail server that pushes a message or notification to the application 504 (e.g., email client), which would then send its own notification message to the operating system 505, [0073] lines 12-15; this specification is a solution to the problem described at [0019], "For example, if the user were to receive an email message via an email client running on a host operating system of the local computer", [0019] lines 11-13; see also definition of notification in paragraph [0023], with "As an example, an email client, upon receiving a new email, may send a notification to the operating system on which the email client is executing such that the operating system may alert the user about the new email via a pop-up dialog.", [0023] lines 18-22), and the first application and the second application are applications in a system carried by a simulator (see FIG. 6, where the second application is the Email App 602A and the first application is the virtual desktop 601A, and both are "carried by" the workspace environment 600, which is the simulator, see all of [0076], but specifically, "The user of the client device may interact with the workspace environment 600 to access a remote desktop (e.g., the operating system 505), a virtual application (e.g., the application 504), etc.", [0076] lines 1-3, which specifically mentions the second application mapped to application 504 and the first application mapped to operating system 505); and sending, by the first application, a second message to a simulator application, wherein (the first application is the operating system 505 combined with the interception layer 513, [0072] lines 14-15; "Each time the notification API is called by the application 504, a shadow notification, which is identical or substantially similar in content to the original notification call, may be generated by the notification interception layer 513 and sent to the unified application notification framework 501.", [0072] lines 18-23; then, the "workspace environment 600 may receive notifications from a unified application notification framework", [0078] lines 1-2): the second message comprises the identifier of the second application (second message is a copy that is forwarded, [0072] lines 18-23; The unified application notification framework may determine an identifier (ID) for the received notification. The identifier may indicate the virtual application associated with the notification and/or the backend service. ... The identifier may be inserted into the notification by the sender ( e.g., application, notification interception layer, backend service, etc.), [0088] lines 1-9; the framework then sends the notification on to the client workspace, [0090] lines 1-7, specifically with "The unified application notification framework may also send other relevant information, such as the application identifier (ID) corresponding to the virtual application", [0090] lines 4-7), and the second message indicates to the simulator to determine whether to perform reminding on the new message received by the second application (The client workspace may extract the application ID included in the notification (802) to confirm whether the application ID matches one of the applications that are associated with the client workspace. If the application ID does not match, then the client workspace may discard the notification without further processing it. Thus, the method may return to operation 801 to monitor for any other notifications, [0093] lines 9-16; If a match is found with the application ID, then the client workspace may present the notification to the user (803), [0094] lines 1-3).
With respect to claim 19, Ren teaches all of the limitations of claim 18, as noted above. Ren further teaches wherein there are a plurality of first messages (intercept any operating system-level notifications “plural” being sent from the application 504, [0071] lines 5-6).
With respect to claim 20, Ren teaches all of the limitations of claim 18, as noted above. Ren further teaches wherein receiving, by the first application, the first message sent by the second application comprises: receiving, by the first application, the first message sent by the second application through a third application (the second application, which is application 504, sends a notification by means of operating system-level notification interception 508 to the first application, which is the operating system 505, [0071] lines 1-6; in the context of FIG. 6, operating system 505 is a remote desktop, [0076] lines 1-3; from the user's point of view, 601 and 505 are a single application called a "virtual desktop", read the rest of [0076] and [0003]; this pathway/channel creates a shadow notification and sends through framework 501, which is the third application, see [0072] lines 1-23).
With respect to claim 21, Ren teaches all of the limitations of claim 18, as noted above. Ren further teaches wherein the first message further comprises: a quantity of new messages received by the second application (application 504 generates operating system level notifications, [0071] lines 5-6; these include “badge” notifications, [0071] lines 21-22; see FIG. 6 reference characters 603A-D, where badge notifications include counters of pending notifications, [0079] lines 1-9; and the notification type may also be part of the filter criterion, [0089] line 10); and content of the new message received by the second application (content of notification includes “contains a message”, [0023] lines 1-6; primary example given is an email received from an email client: For example, the backend service 511 may be a mail server that pushes a message or notification to the application 504 (e.g., email client), which would then send its own notification message to the operating system 505, [0073] lines 12-15; this specification is a solution to the problem described at [0019], "For example, if the user were to receive an email message via an email client running on a host operating system of the local computer", [0019] lines 11-13; see also definition of notification in paragraph [0023], with "As an example, an email client, upon receiving a new email, may send a notification to the operating system on which the email client is executing such that the operating system may alert the user about the new email via a pop-up dialog.", [0023] lines 18-22).
With respect to claim 22, Ren teaches all of the limitations of claim 18, as noted above. Ren further teaches wherein the simulator is an Android simulator (server farm executes operating systems including Android, [0044] lines 1-4]; The user of the client device may interact with the workspace environment 600 to access a remote desktop (e.g., the operating system 505), a virtual application (e.g.,
the application 504), etc... [where], the workspace environment 600 may allow a user ( e.g., "John Smith") to sign in and access one of UI elements ( e.g., icons) that represent virtual desktop environments), [0076] lines 1-7; here, the workspace environment 600 is simulating an OS, Android not specifically shown in context of Fig. 6, but [0076] line 3 is a generic operating system 505, and “The operating system 505 may be a virtual operating system instance such as the guest operating system 330 of FIG. 3”, [0071] lines 7-8; and FIG. 3 is a configured to provide the virtual desktops of FIG. 2, [0047] lines 1-6, which is the embodiment that does describe the Android operating system, [0044] line 3).
With respect to claim 23, Ren teaches all of the limitations of claim 18, as noted above. Ren further teaches wherein the first application is a desktop application ((the second application, which is application 504, sends a notification by means of operating system-level notification interception 508 to the first application, which is the operating system 505, [0071] lines 1-6; in the context of FIG. 6, operating system 505 is a remote desktop, [0076] lines 1-3; from the user's point of view, 601 and 505 are a single application called a "virtual desktop", read the rest of [0076] and [0003]), and the second application is an email application or a video application (For example, the backend service 511 may be a mail server that pushes a message or notification to the application 504 (e.g., email client), which would then send its own notification message to the operating system 505, [0073] lines 12-15; this specification is a solution to the problem described at [0019], "For example, if the user were to receive an email message via an email client running on a host operating system of the local computer", [0019] lines 11-13; see also definition of notification in paragraph [0023], with "As an example, an email client, upon receiving a new email, may send a notification to the operating system on which the email client is executing such that the operating system may alert the user about the new email via a pop-up dialog.", [0023] lines 18-22).
With respect to claim 31, Ren teaches An terminal device, comprising (see FIG. 3, virtualization server 301, [0050] line 1): at least one processor (physical processors 308, [0050] line 6); and at least one memory (physical memory 316, [0050] line 7) comprising instructions that when executed by the at least one processor, cause the terminal device to run a first application to (physical memory 316 may store data, and in some embodiments may store one or more programs, or set of executable instructions. FIG. 3 illustrates an embodiment where firmware 312 is stored within the physical memory 316 of virtualization server 301. Programs or executable instructions stored in the physical memory 316 can be executed by the one or more processors 308 of virtualization server 301, [0050] line 19-26; for the actual instructions see FIGS. 5-8; with a primary focus on how OS-Notification calls work, [0071]-[0072], and the virtual desktop 601 of remote operating system 505 running on simulator/workspace environment 600, [0076]; note FIG. 7 and FIG. 8 show the method, but the OS notification call pathway is best shown in FIG. 5, and the end result is best shown in FIG. 6).
Regarding the rest of claim 31, incorporating the rejection of claim 18, claim 31 is rejected for a substantially similar rationale.
With respect to claim 32, incorporating the rejection of claim 31 and claim 19, claim 32 is rejected for a substantially similar rationale.
With respect to claim 33, incorporating the rejection of claim 31 and claim 20, claim 33 is rejected for a substantially similar rationale.
With respect to claim 34, incorporating the rejection of claim 31 and claim 21, claim 34 is rejected for a substantially similar rationale.
With respect to claim 35, incorporating the rejection of claim 31 and claim 22, claim 35 is rejected for a substantially similar rationale.
With respect to claim 36, incorporating the rejection of claim 31 and claim 23, claim 36 is rejected for a substantially similar rationale.
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) 24-30 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0310858 A1 (Ren) in view of US 2007/0174786 A1 (Doi)
With respect to claim 24, Ren teaches A message reminding method, comprising (see FIGS. 5-8; with a primary focus on how OS-Notification calls work, [0071]-[0072], and the virtual desktop 601 of remote operating system 505 running on simulator/workspace environment 600, [0076]; note FIG. 7 and FIG. 8 show the method, but the OS notification call pathway is best shown in FIG. 5, and the end result is best shown in FIG. 6): receiving, by a simulator, a first message sent by a first application, wherein (simulator is the workspace environment 600: "The workspace environment 600 may receive notifications from a unified application notification framework", [0078] lines 1-2; the first application is the operating system 505 combined with the interception layer 513, [0072] lines 14-15; "Each time the notification API is called by the application 504, a shadow notification, which is identical or substantially similar in content to the original notification call, may be generated by the notification interception layer 513 and sent to the unified application notification framework 501.", [0072] lines 18-23; then, the "workspace environment 600 may receive notifications from a unified application notification framework", [0078] lines 1-2): the first message comprises an identifier of a second application (first message is the copy that is forwarded, [0072] lines 18-23; The unified application notification framework may determine an identifier (ID) for the received notification. The identifier may indicate the virtual application associated with the notification and/or the backend service. ... The identifier may be inserted into the notification by the sender ( e.g., application, notification interception layer, backend service, etc.), [0088] lines 1-9; the framework then sends the notification on to the client workspace, [0090] lines 1-7, specifically with "The unified application notification framework may also send other relevant information, such as the application identifier (ID) corresponding to the virtual application", [0090] lines 4-7), the second application is an application that receives a new message (second application is application 504: For example, the backend service 511 may be a mail server that pushes a message or notification to the application 504 (e.g., email client), which would then send its own notification message to the operating system 505, [0073] lines 12-15; this specification is a solution to the problem described at [0019], "For example, if the user were to receive an email message via an email client running on a host operating system of the local computer", [0019] lines 11-13; see also definition of notification in paragraph [0023], with "As an example, an email client, upon receiving a new email, may send a notification to the operating system on which the email client is executing such that the operating system may alert the user about the new email via a pop-up dialog.", [0023] lines 18-22), and the first application and the second application are applications in a system carried by the simulator (see FIG. 6, where the second application is the Email App 602A and the first application is the virtual desktop 601A, and both are "carried by" the workspace environment 600, which is the simulator, see all of [0076], but specifically, "The user of the client device may interact with the workspace environment 600 to access a remote desktop (e.g., the operating system 505), a virtual application (e.g., the application 504), etc.", [0076] lines 1-3, which specifically mentions the second application mapped to application 504 and the first application mapped to operating system 505); determining, by the simulator, a corresponding second window identifier based on the identifier of the second application (application ID matches one of the applications that are associated with the client workspace, [0093] lines 11-12; the determining is the "matching" where the identifier of the second application is the one coming from the unified application notification framework, and this is compared against the second window ID which is "one of the applications that are associated with client workspace"; note in this reference applications and windows are collectively referred to as “application windows”: see [0040] line 6).
Ren does not teach “a mouse focus window”. Therefore Ren does not teach determining, by the simulator based on the second window identifier and a window identifier of a mouse focus window, whether to perform reminding on the new message received by the second application.
However, Doi teaches and determining, by the simulator based on the second window identifier and a window identifier of a mouse focus window, whether to perform reminding on the new message received by the second application (see FIG. 8, where “It is judged whether the identifier of the window where the event has occurred matches the identifier of the active window. If the window identifiers match, that is, if the event has occurred in the active window, the processing proceeds to step S25”, [0072] lines 18-22; where S25 is "[Step S25] If the event has occurred in the active window, a pop-up message appears to notify the operator that the event has occurred and the processing ends", [0072] lines 30-33; the simulator, which is already taught by Ren, is the “framework window”, see [0072] line 2; see also [0051]-[0051] for the CPU/hardware for perform the functions, and [0054] for the introduction of the framework window and notification API; active window is defined as “having the input focus”, [0029] lines 7-8; and the input includes a mouse, [0051] line 9).
It would have been obvious to one skilled in the art before the effective filing date to combine Ren with Doi because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Ren discloses a system that teaches all of the claimed features except for how and why to use a window identifier of a mouse focus window. Doi teaches why this is necessary in the background section:
...the operator can perform input processing only in an active window having the input focus.
(Doi [0006] lines 2-3). And,
...The operator, who cannot miss an important message, must check the message each time the message display button appears, interrupting the processing each time...
(Doi [0012] lines 6-9). And, finally:
In view of the foregoing, it is an object of the present invention to provide a computer-readable recording medium having recorded a message display control program and a message display control apparatus for informing the user of the occurrence of a message together with its severity and urgency without interfering with the user's operation.
(Doi [0013]).
A person having skill in the art would have a reasonable expectation of successfully incorporating the decision of whether to display a pop-up notification using the active window ID as a decision point in the system and method of Ren by modifying Ren with the decision of checking the active window S23 of Doi in order to avoid interfering with the user’s operation unnecessarily. Therefore, it would have been obvious to combine Ren with Doi to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 25, Ren in view of Doi teaches all of the limitations of claim 24, as noted above. Ren further teaches wherein the first message is sent by the second application to the first application (the second application, which is application 504, sends a notification by means of operating system-level notification interception 508 to the first application, which is the operating system 505, [0071] lines 1-6; in the context of FIG. 6, operating system 505 is a remote desktop, [0076] lines 1-3; from the user's point of view, 601 and 505 are a single application called a "virtual desktop", read the rest of [0076] and [0003]; notification is intercepted by interception layer 513, [0072] lines 1-2, but at least one embodiment has 513 combined with operating system 505, [0072] lines 14-15, so the notification is still received by the "first application").
With respect to claim 26, Ren in view of Doi teaches all of the limitations of claim 24, as noted above. Ren further teaches wherein the first message is sent by the second application to the first application through a third application (the second application, which is application 504, sends a notification by means of operating system-level notification interception 508 to the first application, which is the operating system 505, [0071] lines 1-6; in the context of FIG. 6, operating system 505 is a remote desktop, [0076] lines 1-3; from the user's point of view, 601 and 505 are a single application called a "virtual desktop", read the rest of [0076] and [0003]; pathway/channel creates a shadow notification and sends through framework 501, which is the third application, see [0072] lines 1-23).
With respect to claim 27, Ren in view of Doi teaches all of the limitations of claim 24, as noted above. Ren does not teach wherein determining, by the simulator based on the second window identifier and the window identifier of the mouse focus window, whether to perform the reminding on the new message received by the second application comprises: when the simulator determines that the second window identifier is different from the window identifier of the mouse focus window, determining, by the simulator, to perform the reminding on the new message received by the second application.
However, Doi teaches wherein determining, by the simulator based on the second window identifier and the window identifier of the mouse focus window, whether to perform the reminding on the new message received by the second application comprises: when the simulator determines that the second window identifier is different from the window identifier of the mouse focus window, determining, by the simulator, to perform the reminding on the new message received by the second application ([Step S24] If the identifier of the window where the event has occurred does not match the identifier of the active window, that is, if the event has occurred in an inactive window, a notification icon is illuminated on the active window screen, and the processing ends, [0072] lines 23-27; the simulator, which is already taught by Ren, is the “framework window”, see [0072] line 2; see also [0051]-[0051] for the CPU/hardware for perform the functions, and [0054] for the introduction of the framework window and notification API; active window is defined as “having the input focus”, [0029] lines 7-8; and the input includes a mouse, [0051] line 9).
It would have been obvious to one skilled in the art before the effective filing date to combine Ren with Doi because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Ren discloses a system that teaches all of the claimed features except for how and why to use a window identifier of a mouse focus window. Doi teaches why this is necessary in the background section:
...the operator can perform input processing only in an active window having the input focus.
(Doi [0006] lines 2-3). And,
...The operator, who cannot miss an important message, must check the message each time the message display button appears, interrupting the processing each time...
(Doi [0012] lines 6-9). And, finally:
In view of the foregoing, it is an object of the present invention to provide a computer-readable recording medium having recorded a message display control program and a message display control apparatus for informing the user of the occurrence of a message together with its severity and urgency without interfering with the user's operation.
(Doi [0013]).
A person having skill in the art would have a reasonable expectation of successfully incorporating the decision of whether to display a pop-up notification using the active window ID as a decision point in the system and method of Ren by modifying Ren with the decision of checking the active window S23 of Doi in order to avoid interfering with the user’s operation unnecessarily. Therefore, it would have been obvious to combine Ren with Doi to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 28, Ren in view of Doi teaches all of the limitations of claim 27, as noted above. Ren does not teach further comprising: when the simulator determines that the second window identifier is the same as the window identifier of the mouse focus window, determining, by the simulator, not to perform the reminding on the new message received by the second application.
However, Doi teaches further comprising: when the simulator determines that the second window identifier is the same as the window identifier of the mouse focus window, determining, by the simulator, not to perform the reminding on the new message received by the second application ([Step S25] If the event has occurred in the active window, a pop-up message appears to notify the operator that the event has occurred and the processing ends, [0072] lines 30-33; in this reference, the “pop-up” refers to receiving the message in the active window, not an illumination of an icon which is the “reminding” to the check the new message: “If the window status confirmation block 1c confirms that the window from which the notification information has been obtained is active, the pop-up message display block 1d displays a pop-up message on the screen in accordance with the notification information, [0033]; note in this reference a “window” refers to the process and a “screen” refers to the actual screen, “In the subsequent description, a window processing block which performs processing in accordance with a window processing program will be referred to as a window, and a window displayed on the screen will be referred to as a window screen, [0029] lines 12-16).
It would have been obvious to one skilled in the art before the effective filing date to combine Ren with Doi because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Ren discloses a system that teaches all of the claimed features except for how and why to use a window identifier of a mouse focus window. Doi teaches why this is necessary in the background section:
...the operator can perform input processing only in an active window having the input focus.
(Doi [0006] lines 2-3). And,
...The operator, who cannot miss an important message, must check the message each time the message display button appears, interrupting the processing each time...
(Doi [0012] lines 6-9). And, finally:
In view of the foregoing, it is an object of the present invention to provide a computer-readable recording medium having recorded a message display control program and a message display control apparatus for informing the user of the occurrence of a message together with its severity and urgency without interfering with the user's operation.
(Doi [0013]).
A person having skill in the art would have a reasonable expectation of successfully incorporating the decision of whether to display a pop-up notification using the active window ID as a decision point in the system and method of Ren by modifying Ren with the decision of checking the active window S23 of Doi in order to avoid interfering with the user’s operation unnecessarily. Therefore, it would have been obvious to combine Ren with Doi to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 29, Ren in view of Doi teaches all of the limitations of claim 24, as noted above. Ren further teaches wherein the first message further comprises: a quantity of new messages received by the second application (application 504 generates operating system level notifications, [0071] lines 5-6; these include “badge” notifications, [0071] lines 21-22; see FIG. 6 reference characters 603A-D, where badge notifications include counters of pending notifications, [0079] lines 1-9; and the notification type may also be part of the filter criterion, [0089] line 10); and content of the new message received by the second application (content of notification includes “contains a message”, [0023] lines 1-6; primary example given is an email received from an email client: For example, the backend service 511 may be a mail server that pushes a message or notification to the application 504 (e.g., email client), which would then send its own notification message to the operating system 505, [0073] lines 12-15; this specification is a solution to the problem described at [0019], "For example, if the user were to receive an email message via an email client running on a host operating system of the local computer", [0019] lines 11-13; see also definition of notification in paragraph [0023], with "As an example, an email client, upon receiving a new email, may send a notification to the operating system on which the email client is executing such that the operating system may alert the user about the new email via a pop-up dialog.", [0023] lines 18-22).
With respect to claim 30, Ren in view of Doi teaches all of the limitations of claim 24, as noted above. Ren further teaches wherein: a reminding manner for performing the reminding on the new message received by the second application comprises at least one of: application icon flickering, application window flickering, a pop-up window, a notification, and application window shaking (reminding manner is the operating system level notifications sent by application 504, and sent through the OS-notification pathway 508, [0071] lines 1-6), and the pop-up window or the notification comprises a quantity of new messages or content of the new message (at least taught by application 504 generates operating system level notifications, [0071] lines 5-6; these include “badge” notifications, [0071] lines 21-22; see FIG. 6 reference characters 603A-D, where badge notifications include counters of pending notifications, [0079] lines 1-9; and the notification type may also be part of the filter criterion, [0089] line 10; and content of notification includes “contains a message”, [0023] lines 1-6; primary example given is an email received from an email client: For example, the backend service 511 may be a mail server that pushes a message or notification to the application 504 (e.g., email client), which would then send its own notification message to the operating system 505, [0073] lines 12-15; this specification is a solution to the problem described at [0019], "For example, if the user were to receive an email message via an email client running on a host operating system of the local computer", [0019] lines 11-13; see also definition of notification in paragraph [0023], with "As an example, an email client, upon receiving a new email, may send a notification to the operating system on which the email client is executing such that the operating system may alert the user about the new email via a pop-up dialog.", [0023] lines 18-22).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20210060429 A1 (Juenger) - Techniques for managing notifications are described. In an example, a computing device presents content in an application window based on an execution of an application. Notification data is received by a computing device. Based on a context associated with the computing device, such as whether the application window is the foreground and whether the notification data is associated with the application or such as the operational mode of the computing device, a determination is made whether to present a corresponding notification in-context within the application window or in a pop-up window. Otherwise, the notification is added to a notification list and can be summarized in a notification summary, [Abstract].
10,924,570 B2 (Becker) - In one embodiment, a computer system receives a signal to associate a website with an entity on a user interface. The entity is managed by an operating system running on the computer system. The computer system associates the entity with a push channel that is configured to push updates for the website. The push channel is configured with the entity as an endpoint. An update is received via the push channel at the operating system and the computer system associates the update with the entity by correlating the endpoint of the push channel to the entity. The computer system then causes a notification to be output for the entity on the user interface using the operating system, [Abstract].
US 2022/0114045 A1 (Koehler) - In a kiosk or informational display, an apparatus for detecting and remediating problems, failures, and anomalies includes a data collection agent configured to collect original data over time associated with components, operation, and configuration of the managed computer system, a monitoring and learning module configured to process the original data and generate a historic record that includes time-based data, such as one or more time-based lists, an alert detection system that includes a sensor having associated therewith one of the time-based lists. The sensor is activated when sensor condition(s) are met, which includes evaluating the sensor condition(s) using at least the time-based list and a current-time value of the components, operation, and configuration of the managed computer system. The apparatus includes a remediation action module configured to effect at least one of a plurality of predetermined actions when the sensor is activated, [Abstract].
US 2013/0346521 A1 (Arabo) - A method comprising of receiving, by a user system that includes at least a processor system having at least one processor and a memory system, a first push notification associated with a first priority level for display on the user system; receiving, by the user system, a second push notification associated with a second priority level for display on the user system, the second priority level being higher than the first priority level; and displaying, by the user system, the second push notification prior to the first push notification based on the first and second priority level, [Abstract].
US 2021/0105244 A1 (O’Rourke) - Systems and techniques are described that enable users to interact and share content through a social network application and/or service with other users. A social networking system may determine that a first application and a second application are installed on a device and are both useable to share content between a first account and one or more contact accounts. The social networking system may receive content associated with the first application and the second application and may generate a notification associated with the content. The social networking system may determine which of the first application or the second application to use to present the notification, and may output the notification to the determined first application and/or the second application, [Abstract]; see also FIG. 11, teaching the determining limitations of claim 24 with the window ID, [0284].
US 2012/0226742 A1 (Momchilov) - Methods and systems for transparent user interface integration between remote ("published") applications and their local counterparts are described, providing a seamless, unified user experience, and allowing integration of a start menu, dock, taskbar, desktop shortcuts, windows, window and application switching, system tray elements, client-to-host and host-to-client file type association, URL redirection, browser cookie redirection, token redirection, status message interception and redirection, and other elements. These methods and systems further enhance theme-integration between a client and remote desktop or virtual machine by remoting all UI elements to a recipient for generation, including text controls, buttons, progress bars, radio buttons, list boxes, or other elements; presenting them with the receiver's product and OS-specific UI; and returning status back to the sender. This may achieve a more unified and transparent UI integration, Furthermore, international text may be correctly received in cross-language environments, or translated into the language of the presenting environment, [Abstract]; see also FIG. 3A, which teaches the window/process identifiers, but the identifiers are first discussed in the context of FIG. 2, [0065].
US 9,946,436 B2 (Rolih) - An example method includes receiving, at a mobile device, one or more user selections by a user of the mobile device, where each user selection indicates a respective type of data item to be presented on the mobile device. The method also includes receiving, at the mobile device, one or more data items. The method also includes identifying data items that are associated with the types of data items to be presented on the mobile device, and responsive to identifying data items that are associated with the types of data items to be presented on the mobile device, presenting, on the mobile device, a dynamic icon to present the identified data items, [Abstract].
US 2020/0159950 A1 (Bodin) - The present disclosure relates to digital experience development platforms and, more particularly, to an intelligent digital experience development platform configured to assist different users in the development, design and deployment of digital applications. A computer-implemented method includes: registering, by a computing device, user registration information for a first user and a second user of a collaborative software development environment; accessing, by the computing device, a policy library of security policies providing permissions for sharing information within the collaborative software development environment; assigning, by the computing device, one or more of the security policies to the first user and the second user; receiving, by the computing device, a search request from the first user for the second user; searching, by the computing device, the user registration information for the second user; and determining, by the computing device, that access can be granted to the first user to collaborate with the second user based on the one or more of the security policies, [Abstract].
US 9774697 B2 (Li) - Embodiments of the present invention provide a method for pushing notification, notification server, user equipment and a system, relating to the communication field, which can increase the pushing flexibility and improve the user experience. the push notification method applied to the notification server, comprising: receiving the service message sent by the application program server, service message comprises: service notification, a user attribute and a first application program mark; The first application program mark and user attribute obtaining terminal state grade table, terminal state grade table for indicating an application program used in each user equipment of the level according to the service message screening terminal state in the terminal state grade table level greater than or equal to the preset state level of n user equipment as the target user equipment. n is an integer greater than or equal to 1; sending the service notification to the target user equipment. The embodiment of the invention claims a push method notification, notification server, user equipment and system for service notification push, [Abstract].
JPH08129527A (JP ‘527) - The terminal control system of the first invention has a notification means for notifying a host computer of an event requiring operator action, a window management means for generating and managing a plurality of windows in a terminal connected to the host computer, an emulator for receiving the event notified by the notification means and performing input/output operations on one of the windows using the window management means based on the received event, and an event processing means for receiving the event notified by the notification means, inquiring of the window management means as to whether the emulator window is focused or not, and notifying the operator of the received event when the emulator window is not focused, [0009].
CN 112148503 A (He) - The invention relates to the technical field of electronic device, claims a method for receiving application message, device, electronic device and readable storage medium; Wherein, the method comprises: obtaining the application white list in the first operating system; when the electronic device is switched to the second operating system, the first operating system is running at the background, monitoring whether the authorization application in the first operating system receives the new message; when monitoring the authorization application receives the new message, sending the notification of the received new message to the second operating system through the interface; The method for receiving application message provided by the invention solves the hardware isolation of multi-system electronic device, the application message between different systems cannot be transmitted, easy to cause the use of one system, the important application message of the other system cannot be transmitted to the problem in the system being used; information connectivity is bad, affecting the use experience of the user, [Abstract].
“Implementing Push Notification Systems for Contextual Activity Sampling System” (2015-Banstola) –
PNG
media_image1.png
412
564
media_image1.png
Greyscale
FIG. 5, [page 12];
As shown in figure 7 providers are the third-party application servers that establish an encrypted connection with APNs and APNs take the responsibility of sending the notification to the device and the application that the notification is intended for. A notification that is arrived at APNs will be stored if a device is offline and this notification is stored for a limited period of time and delivered once the device is online. This ensures the quality of service (QoS). If multiple notifications are sent to a device then only the latest notification will be sent. The maximum size of a payload is 2vkb and any notification exceeding this limit is discarded. [10] The following JSON object shows a payload in APNs.
{
"aps":{
"alert":{
"title":"Game Request",
"body":"Bob wants to play poker",
"action-loc-key":"PLAY"
},
"badge":5
}
}
[pages 13-14];
PNG
media_image2.png
390
692
media_image2.png
Greyscale
[page 15].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL MILLER whose telephone number is (408) 918-7548. The examiner can normally be reached on Monday-Friday from 11am to 5pm (PT).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young, can be reached at telephone number (571) 270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR to authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/D.M./Examiner, Art Unit 2187
/KEVIN L YOUNG/ Supervisory Patent Examiner, Art Unit 2194