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 .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 09/12/2024 and 01/09/2025 . The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claims 33, 35-43, 45-47 and 49-52 are rejected under 35 U.S.C. 103 as being unpatentable over Parks (US 8171137 B1) in view of Scott (US 20100023788 A1).
Regarding claim 33, Parks teaches:
A method, comprising: (Claim 1. A method, performed by a first client device or system having one or more processors and memory storing one or more programs for execution by the one or more processors, the method comprising: )
querying, by a first device, a running status of a first application on the first device. (col 5, line 65 - col 6, line 14. In some implementations, application registration information 214 includes, for each registered application one or more of: an application program identifier, a mime type, and information (e.g., a procedure name, reference to an API, or the like) that enables application transfer application to obtain the application state of the registered application. Optionally, application registration information 214 is maintained by client 102 as a searchable database, table or list. In some implementations, a respective application program stores its own application state information during execution, and thus the application state is updated from time to time. Depending on the type of the applications running, the information type and the size of the application state (e.g., the amount of memory required to store the application state) may be different from one application to another, and may be stored either locally (i.e., on client 102) or remotely, such as on a remotely located server.)
storing, by the first device, application status information, wherein the application status information comprises a correspondence between an identifier of the first application and the running status of the first application; and (col 5, line 65 -col 6, line 5. In some implementations, application registration information 214 includes, for each registered application one or more of: an application program identifier, a mime type, and information (e.g., a procedure name, reference to an API, or the like) that enables application transfer application to obtain the application state of the registered application. Optionally, application registration information 214 is maintained by client 102 as a searchable database, table or list.)
Parks does not appear to explicitly teach: sending, by the first device, the application status information to a second device when the first device is in a sleep state, to enable the second device to determine the running status of the first application.
However, Scott teaches: [0023] Having detected that the higher power domain 101 is preparing to go to sleep (in block 201), application state information 111 is transferred between the two domains (block 202) and this may be a one way process (e.g. from the higher power domain 101 to the lower power domain 102) or a two way process (e.g. synchronization). The application state information 111 may be transferred between the full application 109 running in the higher power domain 101 and the application stub 110 running in the lower power domain 102. This application state information may include details of which applications (e.g. which file sharing applications) are currently running on the computing device and any state information or settings associated with one or more applications that are running, e.g. the files currently being downloaded by a file sharing client. The content of the application state information 111 may be dependent on the applications and/or types of applications which are running in the higher power domain. In an example, the application state information for an OS patching application (which is an example of a file sharing application) may comprise a current list of patches applied to the computer and other configuration data of that computer (e.g. hardware configuration). [0052] There is a synchronization mechanism 704 by which files including the index can be partially or wholly transferred between the main storage and the secondary storage, with synchronization being triggered in many cases by a change in power state 705, e.g. the computer preparing to go to sleep, or resuming from sleep (as described above and shown in FIGS. 2 and 3).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Parks and Scott before them, to include Scott’s application state information communication in Parks’s inter device application transfer. Park already teaches transferring application sate information from a first device to a second device, while Scott teaches pre sleep transfer to ensure that current application status is preserved during sleep transition, thereby improving reliability and continuity of the handoff enabling the receiving device to determine the running status of the application and continue operation bas eon the transferred state.
Regarding claim 35, Scott teaches:
The method according to claim 33, further comprising: updating, by the first device, the stored application status information at a first preset moment before the first device enters the sleep state. ([0036] If it is determined (in block 501) that the only applications running could be run in the lower power domain or that other criteria for going to sleep are met (e.g. manual initiation, a defined period of inactivity or based on time of day), the process of putting the higher power domain to sleep is initiated (block 502). Transfer of application state (block 503) occurs before the higher power domain goes to sleep (block 504). When the higher power domain goes to sleep, any applications currently running on the domain will be suspended. Subsequently, the higher power domain wakes-up (block 505) and this may be triggered by the lower power domain (as shown in FIGS. 2 and 3), by the higher power domain (e.g. based on time of day) or by manual intervention by the user. On wake-up, the application state may be transferred between the lower power and higher power domains (block 506).)
Regarding claim 36, Scott teaches:
The method according to claim 33, wherein the running status of the first application comprises at least an application sleep state and an active state. ([0023] Having detected that the higher power domain 101 is preparing to go to sleep (in block 201), application state information 111 is transferred between the two domains (block 202) and this may be a one way process (e.g. from the higher power domain 101 to the lower power domain 102) or a two way process (e.g. synchronization). The application state information 111 may be transferred between the full application 109 running in the higher power domain 101 and the application stub 110 running in the lower power domain 102. This application state information may include details of which applications (e.g. which file sharing applications) are currently running on the computing device and any state information or settings associated with one or more applications that are running, e.g. the files currently being downloaded by a file sharing client. The content of the application state information 111 may be dependent on the applications and/or types of applications which are running in the higher power domain. In an example, the application state information for an OS patching application (which is an example of a file sharing application) may comprise a current list of patches applied to the computer and other configuration data of that computer (e.g. hardware configuration). This information (which may be referred to as properties of the computer) may enable the corresponding application stub to determine when a new patch needs downloading. Where the application is a file sharing application such as a peer to peer file sharing application, the application state information 111 may include an index file which describes the files that a file sharing application is downloading and the parts of the file that have already been downloaded or are still required. The application state may also include cached data 112 such as files which the application is uploading to another device or which the application has made available to other devices. In other examples, the cached data 112 may include parts of a file that have already been downloaded. The cached data 112 may be transferred between the main storage 105 and the secondary storage 106 (which may also be referred to as a cache).)
Regarding claim 37, Parks teaches:
The method according to claim 33, wherein: the application status information comprises first application code, the first application code comprises first sub-code and second sub-code, the first sub-code indicates the running status of the first application, and the second sub-code indicates the first application. (col 5, line 65 -col 6, line 5. In some implementations, application registration information 214 includes, for each registered application one or more of: an application program identifier, a mime type, and information (e.g., a procedure name, reference to an API, or the like) that enables application transfer application to obtain the application state of the registered application. Optionally, application registration information 214 is maintained by client 102 as a searchable database, table or list. E.N.: The reference explicitly describes a table maintain application related information as shown in paragraphs [0107- 0117] tables 1-4 of the specification; see also col. 5, lines 37-42)
Regarding claim 38, Parks teaches:
The method according to claim 33, wherein: the application status information comprises an application status table, and the application status table comprises the correspondence between the identifier of the first application and the running status of the first application. (col 5, line 65 -col 6, line 5. In some implementations, application registration information 214 includes, for each registered application one or more of: an application program identifier, a mime type, and information (e.g., a procedure name, reference to an API, or the like) that enables application transfer application to obtain the application state of the registered application. Optionally, application registration information 214 is maintained by client 102 as a searchable database, table or list. E.N.: the table or list )
Regarding claim 39, Parks teaches:
The method according to claim 38, wherein: the application status table further comprises a first status bit, the first status bit comprises a first sub-status bit, and the first sub-status bit corresponds to the first application. (col 5, line 65 -col 6, line 5. In some implementations, application registration information 214 includes, for each registered application one or more of: an application program identifier, a mime type, and information (e.g., a procedure name, reference to an API, or the like) that enables application transfer application to obtain the application state of the registered application. Optionally, application registration information 214 is maintained by client 102 as a searchable database, table or list. E.N.: the table or list )
Regarding claim 40, Parks teaches:
The method according to claim 33, further comprising: sending, by the first device, the application status information to the second device before the first device enters the sleep state. ([0024] The first device can store first state information when a change occurs in state of a first processor of the first device. The first device can store second state information when a change occurs in the state of a second processor of the second device, e.g., using information received from the second communications interface of the second device. In some embodiments, the first communications interface can manage storage of the first and second state information. The first device can use the first state information in order to determine whether to perform power-consuming operations that involve the first processor, such as causing the first processor to transition from a sleep mode to a non-sleep mode to process a message. In some embodiments, the first communications interface of the first device can determine whether to wake up the first processor from a sleep mode, e.g., in response to receiving a message from the second communications interface. As an example, the first communications interface can determine that the message from the second device does not require the attention of the first processor allowing the first processor to remain asleep in its last known state, thereby conserving power.)
Regarding claim 41, Scott teaches:
The method according to claim 33, wherein sending, by the first device, the application status information to the second device when the first device is in the sleep state comprises :broadcasting, by the first device, the application status information to the second device at intervals of preset duration when the first device is in the sleep state. ([0030] FIG. 2 shows that the transfer of application state (in block 202) occurs after it has been detected that the higher power domain is preparing to go to sleep (in block 201). In another embodiment, however, the transfer may occur before the detection step (i.e. block 202 before block 201). In such an embodiment, the transfer may be performed periodically between the higher and lower power domains or may be performed substantially continuously. [0032] In order to maintain network connectivity in a transparent manner, network state information may also be transferred between the higher power domain and the lower power domain (block 301), in addition to the application state information 111, as shown in FIG. 3. This state information may include the current IP address, username and password (or other authentication details such as wireless security keys), details of wired/wireless access points that the main processor is allowed to use and any associated authentication or configuration information, etc. This network state information may be transferred following detection that the higher power domain is preparing to go to sleep (in block 202, as shown in FIG. 3) or may alternatively be performed periodically or substantially continuously whilst the main processor is awake. The network state information that is transferred may depend upon whether the higher power domain 101 comprises a network interface 108 (as shown in FIG. 1) or whether there is a single functioning network interface 107 located in the low power domain 102.)
Regarding claim 42, Parks teaches:
The method according to claim 33, further comprising: in response to a request of the second device for querying the running status of the first application, querying, by the first device, the stored application status information to obtain the running status of the first application; and sending, by the first device, the running status of the first application to the second device. (col 7, line 32-46. Upon detecting the triggering condition, client 102-1 determines, in accordance with the stored registration information (214, FIG. 2), that a respective application (e.g., the application running in the foreground of client 102-1) is registered for application state sharing (312), and transmits the application state of the respective application to second client 102-2 (314). For ease of explaining method 300, it shall be assumed that the only application for which an application state is to be transmitted to another device is the foreground application, if any, where the foreground application is the application running in a topmost or foreground application window of first client 102-1. However, in some implementations, described in more detail below with reference to FIGS. 5A-5C, application state for more than one application is transmitted by first client 102-1 to second client 102-2.)
Regarding claim 43, Parks teaches:
An method, comprising. (Claim 1. A method, performed by a first client device or system having one or more processors and memory storing one or more programs for execution by the one or more processors, the method comprising: )
receiving, by a second device, application status information sent by a first device, wherein the application status information comprises a correspondence between an identifier of a first application on the first device and a running status of the first application. (col 7, line 32-38. Upon detecting the triggering condition, client 102-1 determines, in accordance with the stored registration information (214, FIG. 2), that a respective application (e.g., the application running in the foreground of client 102-1) is registered for application state sharing (312), and transmits the application state of the respective application to second client 102-2 (314).)
storing, by the second device, the application status information; and. (col 5, line 65 -col 6, line 5. In some implementations, application registration information 214 includes, for each registered application one or more of: an application program identifier, a mime type, and information (e.g., a procedure name, reference to an API, or the like) that enables application transfer application to obtain the application state of the registered application. Optionally, application registration information 214 is maintained by client 102 as a searchable database, table or list.)
Parks does not appear to explicitly teach: querying, by the second device, the stored application status information when the second device is in a sleep state, to determine the running status of the first application.
However, Scott teaches:[0052] There is a synchronization mechanism 704 by which files including the index can be partially or wholly transferred between the main storage and the secondary storage, with synchronization being triggered in many cases by a change in power state 705, e.g. the computer preparing to go to sleep, or resuming from sleep (as described above and shown in FIGS. 2 and 3).[0053] The choice of which files from the index 703 are copied into the secondary storage 701 may be specified by a caching policy 706. The example files 1-5 shown in FIG. 7 may be used to describe a few example caching policies. In these examples, the higher power domain is asleep, thus the main store 702 is not accessible and the file sharing application stub is running in the secondary processor using the secondary storage 701 only.[0054] In a first example, file 1 shows a file that is not duplicated in the secondary storage, perhaps for space reasons and because that file is not useful to the file sharing application at this time. If the file becomes useful to the offloaded application, it could wake the higher power domain (as in block 204) to retrieve the file into its cache, and then put the higher power domain back to sleep.[0055] In a second example, file 2 shows a whole file being cached. This may be because the file sharing application needs to make this file available to peers. Many file sharing applications operate on a tit-for-tat basis i.e. one must make files available for upload in order to receive good download bandwidth, so this file may be cached in order to satisfy this tit-for-tat policy. In a third example, file 3 shows a partially cached file, e.g. for cases where peers do not need the whole file. In this example, the main storage 702 comprises the whole of file 3, so no further download of this file is required.
Same motivation as claim 1
Regarding claim 45, Scott teaches:
The method according to claim 43, wherein the method further comprises: when the second device is in the sleep state, receiving, by the second device, the application status information that is of the first device and that is broadcast by the first device; and updating, by the second device and based on the application status information of the first device, the application status information that is of the first device and that is stored in the second device. ([0038] The software components running on the host PC 601 (or the higher power domain) include an operating system 603, one or more applications 603 and, where required, the software component which is used in transfer of application state (the Somniloquy daemon) 604. The software components running on the secondary processor include application stubs 605, network configuration software 607 and sleep/wake management software 608. The data transferred between the host PC and the secondary processor (i.e. between the higher power and the lower power domain) may comprise the application state 609, stub configuration details and application layer wake-up filters 610, sleep detection/signaling 611 (for use in detection of sleep/wake events, e.g. in blocks 201 and 205), and a wake-up signal and/or updated state information 612. The data transferred may also include, (e.g. where network connectivity is to be maintained transparently or where network authentication details are required by the lower power domain), details of the current network configuration 613. It will be appreciated that the sleep detection/signaling may be performed in a number of different ways and may involve software and/or hardware based detection.)
Regarding claim 46, Scott teaches:
The method according to claim 43, further comprising: sending, by the second device, a request for querying the running status of the first application to the first device when the second device is in the sleep state. ([0038] The data transferred between the host PC and the secondary processor (i.e. between the higher power and the lower power domain) may comprise the application state 609, stub configuration details and application layer wake-up filters 610, sleep detection/signaling 611 (for use in detection of sleep/wake events, e.g. in blocks 201 and 205), and a wake-up signal and/or updated state information 612. The data transferred may also include, (e.g. where network connectivity is to be maintained transparently or where network authentication details are required by the lower power domain), details of the current network configuration 613. It will be appreciated that the sleep detection/signaling may be performed in a number of different ways and may involve software and/or hardware based detection.)
Regarding claim 47, Parks teaches the elements of claim 1 as outlined above. Park also teaches:
A device, comprising: one or more processors; and a memory coupled to the one or more processors and configured to store computer program code, the computer program code comprising computer instructions which, when executed by the one or more processors, enable the device to perform the following operations. ( Claim 16. A client device or system, comprising: one or more communication interfaces, including a near field communication transceiver; one or more processors; and memory storing one or more programs for execution by the one or more processors, the one or more programs comprising instructions to: )
Claims 49-51 recite commensurate subject matter as claims 37-42. Therefore, they are rejected for the same reasons.
Claims 34, 44 and 48 are rejected under 35 U.S.C. 103 as being unpatentable over Parks (US 8171137 B1) in view of Scott (US 20100023788 A1) and further view of Elzur (US 20080232290 A1).
Regarding claim 34, Parks does not appear to explicitly teach :
The method according to claim 33, wherein: the first device comprises a main processor and an auxiliary processor, querying, by the first device, the running status of the first application on the first device comprises: querying, by the auxiliary processor, the running status of the first application on the first device before the main processor enters a main processor sleep state, storing, by the first device, the application status information comprises: querying, by the auxiliary processor, the running status of the first application on the first device before the main processor enters a main processor sleep state, storing, by the first device, the application status information comprises:
However, Elzur teaches: ([0024] FIG. 2 is a block diagram of an exemplary network node comprising an energy management entity, in accordance with an embodiment of the invention. Referring to FIG. 2, the network node 202 may comprise a host subsystem 108 and a networking subsystem 106 similar to or the same as the network nodes 102 described with respect to FIG. 1. Furthermore, the host subsystem 108 may comprise a chipset 202 and operations of the host subsystem 108 may be managed by an operating system 204.[0025] Although FIG. 2 depicts a network node comprising a separate host subsystem and networking subsystem, the invention is not so limited. For example, the networking subsystem 106, the EME 110, and the host subsystem 108 may all be implemented in the chipset 204. For another example, the EME 110 may be implemented in the host subsystem 108 and may provide information for managing power consumption and/or data rate to the networking subsystem 106. In this regard, the networking subsystem 106 may comprise hardware and/or software adapted to enable receiving information for the EME 110 and utilizing that information to make power management and/or data rate decisions. [0029] In operation, a number of factors may be utilized to determine or characterize the activity in the network node 202. In this regard, current and/or expected transactions in the host subsystem 108 and/or on the link 103 may be determined based on activity in the node 202. Accordingly, computational capabilities of the node 202 and/or data rates on the link 103 may be adjusted, for example, to a most energy efficient configuration that still meets the demands of the current and/or expected transactions. Exemplary factors which may be utilized to determine activity in the node 202 may comprise data currently being and/or waiting to be processed, data currently being or waiting to be transferred between portions of the chipset 204, data currently being or waiting to be transferred between the host subsystem 108 and the networking subsystem 106, a state of an application running in the node 202, and/or a state of the operating system 206. Another factor which may be utilized to characterize the activity in the node 202 may be the role of the node 202. For example, the node 202 may be a file server and the EME may ensure it is not turned off of slowed in the presence of some transactions (either by their size, importance, urgency, source, etc.). The EME 110 may inspect definition files to assess the role of the machine and for instance in case the physical node is subject to virtualization (e.g. VMware ESX), it may take into account the state of all Virtual machines (VMs or Guest OS) running on the node before determining any action. It may consult with a hypervisor, user, and/or scripts that control the node and the role of the VMs, the transactions driven by the VMs and their state etc. before taking any action for the node 202. Another factor which may be utilized to characterize the activity in the node 202 may be recent transactions on the link 103. In this regard, the node 202 may use deep packet inspection to determine the status and progress of network transactions. Furthermore, network transactions may comprise information exchanged between energy management entities and thus inspection of these transactions may enable determining activity in other network nodes.)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Parks, Scott, and Elzur before them, to include Elzur’s EME(i.e. suitable circuity/logic/code) in Scott’s and Parks’s systems. One would have been motivated to make such a combination to more efficiently manage power consumption and communication by having a dedicated entity as taught by Elzur’s.
Scott teaches: storing, by the main processor, the application status information, and sending, by the first device, the application status information to the second device when the first device is in the sleep state, to enable the second device to determine the running status of the first application comprises: sending, by the auxiliary processor, the application status information to the second device before the main processor enters the main processor sleep state, to enable the second device to determine the running status of the first application. (0052] There is a synchronization mechanism 704 by which files including the index can be partially or wholly transferred between the main storage and the secondary storage, with synchronization being triggered in many cases by a change in power state 705, e.g. the computer preparing to go to sleep, or resuming from sleep (as described above and shown in FIGS. 2 and 3).[0053] The choice of which files from the index 703 are copied into the secondary storage 701 may be specified by a caching policy 706. The example files 1-5 shown in FIG. 7 may be used to describe a few example caching policies. In these examples, the higher power domain is asleep, thus the main store 702 is not accessible and the file sharing application stub is running in the secondary processor using the secondary storage 701 only.[0054] In a first example, file 1 shows a file that is not duplicated in the secondary storage, perhaps for space reasons and because that file is not useful to the file sharing application at this time. If the file becomes useful to the offloaded application, it could wake the higher power domain (as in block 204) to retrieve the file into its cache, and then put the higher power domain back to sleep.[0055] In a second example, file 2 shows a whole file being cached. This may be because the file sharing application needs to make this file available to peers. Many file sharing applications operate on a tit-for-tat basis i.e. one must make files available for upload in order to receive good download bandwidth, so this file may be cached in order to satisfy this tit-for-tat policy. In a third example, file 3 shows a partially cached file, e.g. for cases where peers do not need the whole file. In this example, the main storage 702 comprises the whole of file 3, so no further download of this file is required.)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Parks and Scott before them, to include Scott’s application state information communication in Parks’s inter device application transfer. Park already teaches transferring application sate information from a first device to a second device, while Scott teaches pre sleep transfer to ensure that current application status is preserved during sleep transition, thereby improving reliability and continuity of the handoff enabling the receiving device to determine the running status of the application and continue operation bas eon the transferred state.
Claims 44 and 48 recite commensurate subject matter as claim 34. Therefore, they are rejected for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199