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 .
2. This action is in response to the Amendment filed on 12/01/2025. Claims 1-3, 5, 6, 8-14, 17-19, and 21 are pending in the case.
Applicant Response
In Applicant’s response dated 12/01/2025 Applicant amended claims 1,2, and 12 and argued against all objections and rejections previously set forth in the Office Action dated 07/01/2025.
Examiner Comments
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 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.
Claim Rejections - 35 USC § 103
5. 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.
6. Claims 1-3, 5-6, 8-14, 17-19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Van Os (Pub. No.: US 20140074483 A1, Pub. Date: March 13, 2014) in view of Powell (Pub. No.: US 20180300187 A1 Pub. Date: 2018-10-18) in further view of Pierre (Pub. No.: US 20030070182 A1 Pub. Date: 2003-04-10) in further view of Rajesh (NPL: Title: Adaptive Automation: Leveraging Machine Learning to Support Uninterrupted Automated Testing of Software Applications Pub. Date: 04/08/2015)
Regarding independent claim 1,
Van Os teaches a computer-implemented method for mitigating unexpected events during a replay of operations by a digital assistant device (see Van Os: Fig.4, [0156], illustrating a computer implemented method for handling user-initiated and system-initiated interruptions while the digital assistant is delivering navigation), the method comprising:
selecting, by the digital assistant device, an action dataset based on a received command (see Van Os: Fig.4, [0158], “Upon the first input being received from the user, the digital assistant initiates (404) a first information provision process in response to receipt of the first input.”), … (see Van Os: Fig.4, [0113], “digital assistant takes the sequence of words or tokens ("token sequence") generated by the speech-to-text processing module 330, and attempts to associate the token sequence with one or more "actionable intents" recognized by the digital assistant. An "actionable intent" represents a task that can be performed by the digital assistant, and has an associated task flow implemented in the task flow models 354.”, the actionable intents contains instructions and event data that is required to complete the received command instruction), wherein the action dataset is a data structure storing instructions for a set of reproducible functions that are associated with an application installed on the digital assistant device (see Van Os: Fig.1, [0113], “The associated task flow is a series of programmed actions and steps that the digital assistant takes in order to perform the task. The associated task flow is a series of programmed actions and steps that the digital assistant takes in order to perform the task. [0103], The one or more processors 304 execute these programs, modules, and instructions, and reads/writes from/to the data structures.”, i.e., Examiner notes that the actionable intents are a collection of predefined instructions or tasks that the digital assistance perform based on the user command and the task flow models 354 is a data structure that store program instructions in memory 302 and contains program action instructions that reproduce or invoke or replay actions of installed application 324), and that were previously recorded by the digital assistance device (see Van Os: Fig.3, [0132], “the service processor 338 can act on behalf of the task flow processor 336 to make a phone call, set a calendar entry, invoke a map search, invoke or interact with other user applications installed (previously recorded) on the user device, and invoke or interact with third party services (e.g. a restaurant reservation portal, a social networking website, a banking portal, etc.). In some embodiments, the protocols and application programming interfaces (API) required by each service can be specified by a respective service model among the services models 356.), wherein the instructions stored by the action dataset include:
a first set of event data interpretable to initiate a particular function of the application (see Van Os: Fig.4, [0158], “the first response and the second response are two discrete navigation instructions (e.g., turn-by-turn directions) generated in response to a single navigation request received from the user.”, The GPS turn by turn direction is an example of event data/ instruction that is initiated in response to user request), see also Van Os: Fig.4, [0163], “After the first information provision process is initiated in response to receipt of the first input from the user, the digital assistant provides (406) the first response to the user. The first response is a speech output among a series of speech outputs to be provided to the user in response to the user request.” i.e., the speech output instruction or event data is a particular function that is initiated and executed by the digital assistant), and,
interpreting, by the digital assistant device, the first set of event data from the selected action dataset in response to the application being executed (see Van Os: Fig.4, [0163], “After the first information provision process is initiated in response to receipt of the first input from the user, the digital assistant provides (406) the first response to the user. The first response is a speech output among a series of speech outputs to be provided to the user in response to the user request.” i.e., the speech output is a particular function that is initiated and executed by the digital assistant and the first input processor can invoke and execute set of instructions such as making a phone call, setting a calendar entry, invoking a map search, invoking a restaurant reservation portal, a social networking website, a banking portal, etc.);
detecting, by the digital assistant device, an occurrence of the particular type of unexpected behavior that interrupts the initiation of the particular function and is not associated with an anticipated condition while the first set of event data is being interpreted by determining a particular graphical user interface (GUI) element associated with the first set of event data is not displayed or queued for display by the digital assistant device while the first set of event data is being interpreted (see Van Os: Fig.4, [0165], “after or concurrent with the provision of the first response to the user, but before provision of the second response to the user, the digital assistant detects (408) an event operable to initiate a second information provision process.” i.e., the speech output is a particular function that is initiated and executed by the digital assistant), … see also Van Os: Fig.4, [0149] stating that the interruption events ( i.e. unexpected behaviors ) are for example an alert item (e.g., a speech output, an alert sound, an alert message, a popup banner, badge, or message) providing content of the reminder or notification to the user. i.e. the event data ( example an alert item (e.g., a speech output, an alert sound, an alert message, a popup banner, badge, or message) are not displayed or queued while the first instruction is being executed and only are displayed when the interruption occurs.”),
As shown above, Van Os teaches or suggests intelligent interruption handling by digital assistant device. The digital assistant device while running or executing a particular function or application process (for example a navigation application) handles unexpected behavior or interruption by providing a response or output message to the interruption event for example by providing speech output in response to the detected interruption.
Van Os does not teach a computer-implemented method wherein:
the instructions stored by the action dataset includes deep link to the application installed on the digital assistant device, and activating, by the digital assistant device, the deep link from the selected action dataset, wherein the activated deep link causes the application to be executed;
the instructions stored by the action dataset includes a set of recovery event data, different from the first set of event data, interpretable to dismiss a particular type of unexpected behavior that interrupts the initiation of the particular function and cause resumption of the particular function of the application, wherein the set of recovery event data includes references or identifiers that correspond to one or more unexpected behaviors;
interpreting, by the digital assistant device, the set of recovery event data based on the particular type of the unexpected behavior, wherein the interpretation of the set of recovery event data causes the digital assistant device to emulate at least one GUI input interaction that automatically dismisses the particular type of unexpected behavior, and causes the initiation of the particular function to resume.
a graphical user interface (GUI) input interaction that automatically dismisses the particular type of unexpected behavior.
However, Powell teach or suggest a computer-implemented method that comprises:
the dataset includes a deep link to the application installed on the digital assistant device (see Powell: Fig.4, [0075], “deep link module 8 may receive from a first application 12A an indication of an action to be performed (502). Deep link module 8 may determine, based on at least the indication of the action to be performed, a plurality of deep links to a plurality of actions performable by a plurality of applications (504).”)
activating, by the digital assistant device, the deep link from the selected action dataset, wherein the activated deep link causes the application to be executed (see Powell: Fig.4, [0075], “Deep link module 8 may select a subset of deep links from the plurality of deep links (506). Deep link module 8 may output for display by UI device 4 a graphical user interface including an indication of each deep link from the subset of deep links (508). UI device 4 may receive an indication of a user input, the user input corresponding to a selection of one of the deep links from the subset of deep links (510). A second application linked to by the selected deep link may perform an action linked to by the selected deep link (512).”)
Because both Van Os and Powell are in the same/similar field of endeavor of a digital assistant device and the use of installed applications ,it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify teaching of Van Os to include the system, comprising a deep link to an application installed on the digital assistant device and activating, by the digital assistant device, the deep link from the selected action dataset, wherein the activated deep link causes the application to be executed as taught by Powell. After modification of Van Os, the installed applications that handle unexpected behavior can also activate deep link to execute applications as taught by Powell. One would have been motivated to make such a combination in order to enhance user experience in using application and increase user engagement by easily setting connection between two Apps.
As shown above, Van Os teaches or suggests intelligent interruption handling by digital assistant device. The digital assistant device while running or executing a particular function or application process (for example a navigation application) handles unexpected behavior or interruption by providing a response or output message to the interruption event for example by providing speech output in response to the detected interruption and Powell teaches or suggests a techniques for dynamically determining relevant deep links to targets of applications running on a computing device.
Van Os and Powell does not teach a computer-implemented method wherein:
the instructions stored by the action dataset includes a set of recovery event data, different from the first set of event data, interpretable to dismiss a particular type of unexpected behavior that interrupts the initiation of the particular function and cause resumption of the particular function of the application, wherein the set of recovery event data includes references or identifiers that correspond to one or more unexpected behaviors;
interpreting, by the digital assistant device, the set of recovery event data based on the particular type of the unexpected behavior, wherein the interpretation of the set of recovery event data causes the digital assistant device to emulate at least one GUI input interaction that automatically dismisses the particular type of unexpected behavior, and causes the initiation of the particular function to resume.
a graphical user interface (GUI) input interaction that automatically dismisses the particular type of unexpected behavior.
However, Pierre teaches the teach a computer-implemented method wherein:
the instructions stored by the action dataset (see Pierre: Fig.4, [0021], “Viewer Manager 240 stores client/user information and viewer interruption scenarios (pause and playback) in User Data 220. i.e. interruption scenarios are instructions that are stores by the action dataset.”), include a set of recovery event data, different from the first set of event data, interpretable to [pause] a particular type of unexpected behavior that interrupts the initiation of the particular function (see Pierre: Fig.4, [0026], “event priority is compared to a table of viewer priority and preferences 116 to determine what actions are appropriate for the event. The viewer priority and preference table 116 comprises event types, event originators, viewer interruption rules and relative priorities. Appropriate responses to incoming events are determined by looking at the event type (email, phone call, etc.) and event source (stockbroker, friend, boss, mom) to determine a relative priority or by looking for an event type and priority previously programmed and stored in a priority table. The priority assignment decision further comprises consideration of interruption rules. Interruption rules determine whether the current message type and originator warrant interruption of the current program. i.e. the preference 116 are a set of recovery event data that are different from the media playlist event data and are interpretable to dismiss/pause the media playlist when particular type of unexpected behavior such as event type (email, phone call, etc.) that interrupts the initiation of the media play function ”) and cause resumption of the particular function of the application (see Pierre: Fig.4, [0029], “given a very high event priority, the present invention will automatically pause the live broadcast when an oven timer times out, so that the viewer can run to the oven, take the roast out and then resume viewing the recorded portion of the live broadcast in time-shifted mode upon returning without missing anything. That is, the recorded portion of the live program, recorded during the pause, is played back after the automatic pause to enable the viewer time to respond to the oven time out and resume viewing without missing any part of his program”), wherein the set of recovery event data includes references or identifiers that correspond to one or more unexpected behaviors (see Pierre: Fig.4, [0035], “All incoming events requesting resources are processed by process Check Resource Availability 118. The viewer priority and preferences 116 (i.e. set of recovery event data that correspond to one or more unexpected behavior are identified by event type preference table) are factored into the event relative priority, so that an event identification indicating an urgent notice from his stockbroker to sell immediately, interrupts at a high priority and a reminder from the dentist does not, based on the preferences and priorities the viewer chooses.”)
interpreting, by the digital assistant device, the set of recovery event data based on the particular type of the unexpected behavior (see Pierre: Fig.4, [0026], “event priority is compared to a table of viewer priority and preferences 116 to determine what actions are appropriate for the event. The viewer priority and preference table 116 comprises event types, event originators, viewer interruption rules and relative priorities. Appropriate responses to incoming events are determined by looking at the event type (email, phone call, etc.) and event source (stockbroker, friend, boss, mom) to determine a relative priority or by looking for an event type and priority previously programmed and stored in a priority table. The priority assignment decision further comprises consideration of interruption rules. Interruption rules determine whether the current message type and originator warrant interruption of the current program. i.e. the preference 116 are a set of recovery event data that are different from the media playlist event data and are interpretable to dismiss/pause the media playlist when particular type of unexpected behavior such as event type (email, phone call, etc.) that interrupts the initiation of the media play function ”), wherein the interpretation of the set of recovery event data causes the digital assistant device to emulate at least one GUI input interaction that automatically [pause] the particular type of unexpected behavior (see Pierre: Fig.4, [0035], “All incoming events requesting resources are processed by process Check Resource Availability 118. The viewer priority and preferences 116 (i.e. set of recovery event data that correspond to one or more unexpected behavior are identified by event type preference table) are factored into the event relative priority, so that an event identification indicating an urgent notice from his stockbroker to sell immediately, interrupts at a high priority and a reminder from the dentist does not, based on the preferences and priorities the viewer chooses.”), and causes the initiation of the particular function to resume (see Pierre: Fig.4, [0029], “given a very high event priority, the present invention will automatically pause the live broadcast when an oven timer times out, so that the viewer can run to the oven, take the roast out and then resume viewing the recorded portion of the live broadcast in time-shifted mode upon returning without missing anything. That is, the recorded portion of the live program, recorded during the pause, is played back after the automatic pause to enable the viewer time to respond to the oven time out and resume viewing without missing any part of his program”),
Because Van Os, Powell, and Pierre address the same issue of handling unexpected notifications and alerts in a digital assistant device graphical user interface while an application is running ,it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify the teaching of Van Os to include a set of recovery event data, different from the first set of event data, interpretable to dismiss a particular type of unexpected behavior that interrupts the initiation of the particular function and cause resumption of the particular function of the application as taught by Pierre. One would have been motivated to make such a combination in order to provide users with enhanced capabilities in controlling notifications and alerts that interrupt computer device applications.
Van Os Powell and Pierre does not explicitly teach or suggest a system that comprises:
a graphical user interface (GUI) input interaction that automatically dismisses the particular type of unexpected behavior.
However, Rajesh teaches the system comprising:
detecting unexpected behavior by determining a particular graphical user interface (GUI) element associated with the first set of event data is not displayed or queued for display by the digital assistant device while the first set of event data is being interpreted (see Rajesh: Section 3.2, Adaptive recovery, states that the system detects when a requires UI element is missing-
PNG
media_image1.png
232
346
media_image1.png
Greyscale
In addition, see Rajesh: Section IV stating “adaptive test recovery for automated user interface testing. The prototype addresses three common issues: missing user interface elements, disruptions to the user interface flow caused by pop-up dialogs and recovery of tests using pre-defined recovery techniques.”)
a graphical user interface (GUI) input interaction that that automatically dismisses the particular type of unexpected behavior (see Rajesh: Section 3.2 describes GUI recovery actions to remove dismiss UI obstacles:
PNG
media_image2.png
348
378
media_image2.png
Greyscale
Because Van Os, Powell, Pierre and Rajesh address the same issue of handling unexpected notifications and alerts in a digital assistant device graphical user interface while an application is running ,it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify the teaching of Van Os to include the system that detect unexpected behavior by determining a particular graphical user interface (GUI) element is not displayed and a system that dismiss the particular type of unexpected behavior and causes the initiation of the particular function to resume as taught by Rajesh. After modification of Van Os, the response to unexpected events such as notification or pop-up can also provide a graphical user interface input interaction action that dismiss or cancel or confirm the unexpected interruptions automatically or manually as taught by Rajesh. One would have been motivated to make such a combination in order to provide users with enhanced capabilities in controlling notifications and alerts that interrupt computer device applications.
Regarding Claim 2,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 1. Van Os further teaches the implemented method wherein at least a portion of the set of event data is associated with the particular type of unexpected behavior and is interpretable to only dismiss the particular type of unexpected behavior (see Van Os: Fig. 4, [0165], “the user can interrupt the digital assistant while the digital assistant is in the process of providing the series of responses for first user input. In some embodiments, after or concurrent with the provision of the first response to the user, but before provision of the second response to the user, the digital assistant detects (408) an event (unexpected behavior) operable to initiate a second information provision process (second set of event data)”)
Regarding Claim 3,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 2. Rajesh further teaches the method wherein an interpretation of at least the portion of the set of recovery event data dismisses the particular type of unexpected behavior (see Rajesh: Section 3.2, Adaptive recovery, states that the system detects when a requires UI element is missing-
PNG
media_image1.png
232
346
media_image1.png
Greyscale
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify the teaching of Van Os to include the system that comprises set of recovery event data that dismiss the particular type of unexpected behavior as taught by Ko. After modification of Van Os, the response to unexpected events such as notification or pop-up can also provide a graphical user interface input interaction action that dismiss or cancel or confirm the unexpected interruptions automatically or manually as taught by Rajesh. One would have been motivated to make such a combination in order to provide users with enhanced capabilities in controlling notifications and alerts that interrupt computer device applications.
Regarding Claim 5,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 1. Van Os further teaches the method wherein the particular type of unexpected behavior is one of a plurality of types of unexpected behavior including pop-up, login prompt, notification, a displayed element, a missing GUI element, or an inactive GUI element (see Van Os : [0149], “When the digital assistant detects that the predetermined trigger event(s) have occurred, the digital assistant or the user device generates and delivers an alert item (e.g., a speech output, an alert sound, an alert message, a popup banner, badge, or message) providing content of the reminder or notification to the user.”)
Regarding Claim 6,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 1. Van Os further teaches the method wherein the particular type of unexpected behavior is determined not associated with the first set of event data. (See Van Os: Fig.4, [0159], the first response and the second response are two discrete speech outputs reading two distinct information items in a list of information items retrieved by the digital assistant in response to the same user request”)
Regarding Claim 8,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 1. Van Os further teaches the computer implemented method wherein the particular type of unexpected behavior is detected based on an error that occurs when the first set of event data is being interpreted (see Van Os: Fig.4, [0173], “for different type of events and responses, a different set of priority parameters are considered in evaluating the relative priority or urgency for delivery (another determination). Therefore, the outcome of the context determination by the interruption handling process often varies from case to case.”)
Regarding Claim 9,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 1. Van Os further teaches the method wherein the particular type of unexpected behavior is determined to interrupt the initiation of the particular function based on another determination that an expected GUI element associated with an interpreted instruction of the first set of event data is unavailable (see Van Os : Fig.4, [0174], “after the first information provision process and the second information provision processes are both initiated and uncompleted (i.e., a complete response has not been provided according to either the first or the second information provision process), the digital assistant determines (412) a relative urgency between the second response and the third response. In some embodiments, the digital assistant determines the relative urgency based on the present context. In some embodiments, the digital assistant gathers the context information for the present time after detecting the concurrent availability of both the second and the third responses.”)
Regarding Claim 10,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 1. Van Os further teaches the method wherein the interpretation of each instruction in the first set of event data corresponds to a set of operations that collective perform the particular function (see Van Os: for e.g., Fig.4, [0158], illustrating that “the first response and the second response are two discrete navigation instructions (e.g., turn-by-turn directions) generated in response to a single navigation request received from the user.” i.e. the instructions of the first input correspond to a particular function such as navigation instruction)
Regarding Claim 11,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 10. Rajesh further teaches the method wherein an interpretation of the recovery set of event data causes the emulation of at least one GUI input interaction and further cause least one of a termination operation, a delay operation, a close operation, an accept operation, or any other operation to dismiss the particular unexpected behavior (see Rajesh: Section 3.2 describes GUI recovery actions to remove dismiss UI obstacles:
PNG
media_image2.png
348
378
media_image2.png
Greyscale
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify the teaching of Van Os to include the system that comprises graphical user interface (GUI) input interaction that that automatically dismisses or close or terminate or accept the particular type of unexpected behavior as taught by Rajesh. After modification of Van Os, the response to unexpected events such as notification or pop-up can also provide a graphical user interface input interaction action that dismiss or cancel or confirm the unexpected interruptions automatically or manually as taught by Rajesh. One would have been motivated to make such a combination in order to provide users with enhanced capabilities in controlling notifications and alerts that interrupt computer device applications.
Regarding independent Claim 12 and 18,
Claim 12 is directed to computer-readable storage medium claim and Claim 18 is a System claim and both the claims have similar/same technical features and claim limitations as Claim 1 and are rejected under the same rationale.
Regarding Claim 13,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 12. Van Os further teaches the method wherein the first set of instructions is interpreted in response to the execution of the referenced application (see Van Os: Fig.4, [0163], “the digital assistant provides (406) the first response to the user. In some embodiments, the first response is a speech output among a series of speech outputs to be provided to the user in response to the user request. In some embodiments, the first response is any one of the series of speech outputs other than the last one of the series of speech outputs. In some embodiments, the first response and the second response are any two responses that are either consecutive responses in a series of responses or separated by one or more other responses.”).
Regarding Claim 14,
Claim 14 is directed to computer-readable storage medium claim that have similar/same technical features and claim limitations as Claim 2 and is rejected under the same rationale.
Regarding Claim 17,
Claim 17 is directed to computer-readable storage medium claim that have similar/ same technical features and claim limitations as Claim 5 and is rejected under the same rationale.
Regarding Claim 19,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 18. Van Os further teaches the method wherein the first set of event data is interpreted in response to the execution of the referenced application (see Van Os: Fig.4, [0163], “the digital assistant provides (406) the first response to the user. In some embodiments, the first response is a speech output among a series of speech outputs (event data) to be provided to the user in response to the user request. In some embodiments, the first response is any one of the series of speech outputs other than the last one of the series of speech outputs. In some embodiments, the first response and the second response are any two responses that are either consecutive responses in a series of responses or separated by one or more other responses.”), and wherein at least a portion of the set of recovery instructions is associated with the detected unexpected behavior (see Van Os: Fig. 4, [0165], “the user can interrupt the digital assistant while the digital assistant is in the process of providing the series of responses for first user input. In some embodiments, after or concurrent with the provision of the first response to the user, but before provision of the second response to the user, the digital assistant detects (408) an event (unexpected behavior) operable to initiate a second information provision process (second set of instructions)”)
Regarding Claim 21,
Van Os, Powell, Pierre and Rajesh teaches all the limitations of Claim 18. Rajesh further teaches the method wherein the one or more processors detect the particular type of unexpected behavior that interrupts the initiation of the particular function while the first set of event data is being interpreted by determining a particular GUI element is not displayed or queued for display by the digital assistant device while the first set of event data is being interpreted (see Rajesh: Section 3.2, Adaptive recovery, states that the system detects when a requires UI element is missing)
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the invention, to modify the teaching of Van Os to include the system that detect unexpected behavior by determining a particular graphical user interface (GUI) element is not displayed and a system that dismiss the particular type of unexpected behavior and causes the initiation of the particular function to resume as taught by Rajesh. After modification of Van Os, the response to unexpected events such as notification or pop-up can also provide a graphical user interface input interaction action that dismiss or cancel or confirm the unexpected interruptions automatically or manually as taught by Rajesh. One would have been motivated to make such a combination in order to provide users with enhanced capabilities in controlling notifications and alerts that interrupt computer device applications.
Response to Arguments
Applicant’s arguments with respect to claim amendments have been considered but are moot considering the new combination of references being used in the current rejection. The new combination of references was necessitated by Applicant’s claim amendments. Therefore, the claims are rejected under the new combination of references as indicated above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
PGPUB
NUMBER:
INVENTOR-INFORMATION:
TITLE / DESCRIPTION
US 7631215 B2
Ikehara; Kiyoshi
Title: Personal Digital Assistant And Data Recovery Method
Description: The present invention relates to a Personal Digital Assistant (hereinafter referred to as PDA) and a data recovery method where internally stored data is recoverable when lost.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZELALEM W SHALU whose telephone number is (571)272-3003. The examiner can normally be reached M- F 0800am- 0500pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Cesar Paula can be reached on (571) 272-4128. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Zelalem Shalu/Examiner, Art Unit 2145
/CESAR B PAULA/Supervisory Patent Examiner, Art Unit 2145