DETAILED ACTION
Notice of Pre-AIA or AIA Status
1.The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
2. Claims 16-20 are objected to because of the following informalities:
3. The dependent claims recite ’the method”. Independent claim 15 recites “An electronic device”. The dependent claims should be consistent with the independent claims. Examiner suggest that the dependent claims should recite “the device ”. Appropriate correction is required.
Claim Rejections - 35 USC § 103
4. 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.
5. Claim(s) 1-5 and 11-19 are rejected under 35 U.S.C. 103 as being unpatentable over Carrara (US Pub.No.2012/01317565) in view of Schieman (US Pub.No.2017/0235469).
6. Regarding claim 1 Carrara teaches an application sensitive behavior reminder method, the method comprising: receiving, by a first electronic device, a first request from a second electronic device, the first request requesting to access first device permission of the first electronic device; in response to the first request, allowing, by the first electronic device, the second electronic device to access the first device permission; receiving, by the first electronic device, a first operation; and displaying, by the first electronic device, a first interface in response to the first operation, the first interface comprising a first prompt, and the first prompt comprising the first icon (abstract and Para:0022 teaches transmitting data from the computing device to an application server, and wherein the method comprises: executing an application at the computing device, wherein an attempt to access a computing resource on the computing device is made by the application; determining that the application is not configured to access the computing resource, in response to the attempt; displaying, in a user interface of the computing device, a permission request to allow the application to access the computing resource; and transmitting data from the computing device to the application server, the data notifying the application server that the attempt to access the computing resource was made by the application when the application was not configured to access the computing resource, and the data being usable by the application server to determine whether a corresponding computing resource on at least one different computing device is likely to be accessed when the application is executed on the different computing device.
Para:0094-0099 teaches in fig.5 at 510, an application (e.g. application 402 of fig. 4) is downloaded from an application server (e.g. application server 268 of fig. 4) to a first mobile device (e.g. mobile device 100), the application being transmitted from the application server 268 to the mobile device 100 at 515. At 530, the first mobile device 100 installs the application 402 downloaded at 520. The installation process may include displaying, to a user in a user interface (e.g. in display 110 of fig. 1), permission requests to access each of the computing resources identified in the installation manifest downloaded to the first mobile device 100 at 520 and associated with the application 402. In, fig. 6A,the permission request may present the option to allow 610 or deny 612 access to each of the listed computing resources.
Para:0106-0108 teaches At 545, the first mobile device 100 displays a permission request to allow the application 402 to access the computing resource that the application 402 is attempting to access at 535, during execution of the application 402. This permission request may be displayed to a user in a user interface of the first mobile device 100. FIG. 6B illustrates an example visual output displaying the `CycleNation` application's permission request 604c for the camera API on `Bob's Device` 600. When viewing the permission request, a user may allow 610' or deny 612' the `CycleNation` application access to the camera API.
At 550, the first mobile device 100 transmits data that notifies the application server 268 of the attempt to access the computing resource by the application 402 made at 535, when the application 402 was not configured to access the computing resource as determined at 540. This data is then received by the application server 268 at 555. At 552, the application 402 may be allowed access to the computing resource if the permission request displayed at 545 is accepted by the user or the access may be otherwise denied).
Carrara teaches all the above claimed limitations but fails to expressly teach displaying a first icon in a status bar based on access permission.
Schieman teaches allowing, by the first electronic device, to access the first device permission and displaying a first icon in a status bar, the first icon indicating that the first device permission is accessed (Figs.1-3 and Para:0011-0012 teaches accesses to a resource on a communication device can be monitored. For example, a resource management application on a device can monitor a number of accesses to a resource made by one or more applications over a monitoring period. In some cases, a user interface can be outputted on the device to display the information associated with one or more resource accesses by an application. In some cases, a user can further review detailed information of the resource access, e.g., the time, the duration, and the location of the device when the access is made through the same or different user interfaces. In some cases, one user interface can be outputted to show the resource accesses information collected by the resource management application and provide a user interface object for the user to set permissions for resource access. Examples of the user interface object can include an icon, a dialogue box, or any other user interface objects that enable the user to make a selection through a user interface action. Examples of the user interface action can include tapping, swiping, clicking, touching, etc.
Para:0013 teaches a screen shot of an example graphic user interface 100 that outputs resource access information for one application according to an implementation. As shown in FIG. 1, the user interface 100 includes the resource access information of Application 1 with respect to different resources. The user interface 100 also includes one or more user interface objects associated with each resource for Application 1. In the illustrated example, the user interface objects are toggles, e.g., toggle 110. The toggle 110 can be displayed as a circle on a bar. The toggle 110 can be tapped or otherwise actuated to change the permission setting. In one example, the circle appears on the left of the toggle 110, which indicates that the permission is off, i.e., denied. In response to receiving user input corresponding to a tap of the toggle 110, the circle can move to the right, which indicates that the permission is on, i.e., granted. In some cases, the toggle 110 can be swiped to change the permission setting. In the illustrated example, the current permission settings for the resources are shown as granted. A user can change the permission of a particular resource using the toggle 110 while viewing the number of times Application 1 has accessed the particular resource).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify the teachings of Carrara to include allowing, by the first electronic device, to access the first device permission and displaying a first icon in a status bar, the first icon indicating that the first device permission is accessed as taught by Schieman in such a setup the user can set the permission in view of the access information and make an informed selection. So, both the privacy protection and the user experience can be improved (para:0012).
7. Regarding claim 2 Carrara teaches the method, wherein the method further comprises: receiving, by the first electronic device, a second operation on the first prompt; and displaying, by the first electronic device, a first permission list in response to the second operation, wherein the first permission list comprises first information, and the first information indicates that the first device permission is accessed by the second electronic device (Fig.5 and Para:0101-0105 teaches At 535, after the installation of the application 402 at 530, the first mobile device 100 executes the application 402. This may be performed in response to a user's direction to execute the application, by selecting an associated application icon, for example. During execution of the application 402, an attempt to access a computing resource on the first mobile device 100 is made by the application 402. In the example scenario described above, this may involve the mobile device 100 accessing a camera API that the `CycleNation` application provides to capture photographs of features on a cycling route. At 540, the first mobile device 100 determines that the application 402 is not configured to access the computing resource, in response to the attempt made at 535. It may do this, for example, by examining the installation manifest associated with the application 402, and determining that the installation manifest fails to identify the computing resource as a computing resource that the application 402 will access on the first mobile device 100 when the application is executed. In the example scenario described above, the installation manifest for the `CycleNation` application does not list the camera API as a computing resource that the application will access when the application is executed. This resulted in a permission request not being displayed for the computing resource during installation. For example, in the `CycleNation` example scenario, the application developer may have added the camera functionality to the application, and uploaded it to the application server without making a corresponding update to the installation manifest. As a further example, additional functionality may be provided by an application, as a result of the application developer adding new features to an application 402 or because a new computing resource is being made available on certain mobile devices.
Para:0106-0108 teaches At 545, the first mobile device 100 displays a permission request to allow the application 402 to access the computing resource that the application 402 is attempting to access at 535, during execution of the application 402. This permission request may be displayed to a user in a user interface of the first mobile device 100. FIG. 6B illustrates an example visual output displaying the `CycleNation` application's permission request 604c for the camera API on `Bob's Device` 600. When viewing the permission request, a user may allow 610' or deny 612' the `CycleNation` application access to the camera API.
At 550, the first mobile device 100 transmits data that notifies the application server 268 of the attempt to access the computing resource by the application 402 made at 535, when the application 402 was not configured to access the computing resource as determined at 540. This data is then received by the application server 268 at 555. At 552, the application 402 may be allowed access to the computing resource if the permission request displayed at 545 is accepted by the user or the access may be otherwise denied).
8. Regarding claim 3 Carrara teaches the method, wherein the method further comprises: receiving, by the first electronic device, a third operation on the first information; and displaying, by the first electronic device, a first control in response to the third operation, wherein the first control is used to manage access of the second electronic device to the first device permission (Fig.5 and Para:0101-0105 teaches At 535, after the installation of the application 402 at 530, the first mobile device 100 executes the application 402. This may be performed in response to a user's direction to execute the application, by selecting an associated application icon, for example. During execution of the application 402, an attempt to access a computing resource on the first mobile device 100 is made by the application 402. In the example scenario described above, this may involve the mobile device 100 accessing a camera API that the `CycleNation` application provides to capture photographs of features on a cycling route. At 540, the first mobile device 100 determines that the application 402 is not configured to access the computing resource, in response to the attempt made at 535. It may do this, for example, by examining the installation manifest associated with the application 402, and determining that the installation manifest fails to identify the computing resource as a computing resource that the application 402 will access on the first mobile device 100 when the application is executed. In the example scenario described above, the installation manifest for the `CycleNation` application does not list the camera API as a computing resource that the application will access when the application is executed. This resulted in a permission request not being displayed for the computing resource during installation. For example, in the `CycleNation` example scenario, the application developer may have added the camera functionality to the application, and uploaded it to the application server without making a corresponding update to the installation manifest. As a further example, additional functionality may be provided by an application, as a result of the application developer adding new features to an application 402 or because a new computing resource is being made available on certain mobile devices.
Para:0106-0108 teaches At 545, the first mobile device 100 displays a permission request to allow the application 402 to access the computing resource that the application 402 is attempting to access at 535, during execution of the application 402. This permission request may be displayed to a user in a user interface of the first mobile device 100. FIG. 6B illustrates an example visual output displaying the `CycleNation` application's permission request 604c for the camera API on `Bob's Device` 600. When viewing the permission request, a user may allow 610' or deny 612' the `CycleNation` application access to the camera API.
At 550, the first mobile device 100 transmits data that notifies the application server 268 of the attempt to access the computing resource by the application 402 made at 535, when the application 402 was not configured to access the computing resource as determined at 540. This data is then received by the application server 268 at 555. At 552, the application 402 may be allowed access to the computing resource if the permission request displayed at 545 is accepted by the user or the access may be otherwise denied).
9. Regarding claim 4 Schieman teaches the method, wherein after the receiving, by the first electronic device, the first operation, the method further comprises: querying, by the first electronic device, an access record of accessing device permission of the first electronic device in a first time period to obtain a first access record, wherein the first time period is before the first operation is received, and the first access record comprises first access data of accessing the first device permission by the second electronic device; and the displaying, by the first electronic device, the first interface, wherein the first interface comprises the first prompt comprises: displaying, by the first electronic device, the first interface based on the first access record, wherein the first interface comprises the first prompt, and the first icon comprised in the first prompt is determined based on the first access data (Figs.1-3 and Para:0011-0012 teaches accesses to a resource on a communication device can be monitored. For example, a resource management application on a device can monitor a number of accesses to a resource made by one or more applications over a monitoring period. In some cases, a user interface can be outputted on the device to display the information associated with one or more resource accesses by an application. In some cases, a user can further review detailed information of the resource access, e.g., the time, the duration, and the location of the device when the access is made through the same or different user interfaces. In some cases, one user interface can be outputted to show the resource accesses information collected by the resource management application and provide a user interface object for the user to set permissions for resource access. Examples of the user interface object can include an icon, a dialogue box, or any other user interface objects that enable the user to make a selection through a user interface action. Examples of the user interface action can include tapping, swiping, clicking, touching, etc.
Para:0013 teaches a screen shot of an example graphic user interface 100 that outputs resource access information for one application according to an implementation. As shown in FIG. 1, the user interface 100 includes the resource access information of Application 1 with respect to different resources. In the illustrated example, the user interface 100 shows that in a particular time period, e.g., the last 7 days, Application 1 has accessed the camera resource 33 times, the contacts resource 78 times, the location resource 89 times, and the microphone resource 47 times. The user interface 100 also includes one or more user interface objects associated with each resource for Application 1. In the illustrated example, the user interface objects are toggles, e.g., toggle 110. The toggle 110 can be displayed as a circle on a bar. The toggle 110 can be tapped or otherwise actuated to change the permission setting. In one example, the circle appears on the left of the toggle 110, which indicates that the permission is off, i.e., denied. In response to receiving user input corresponding to a tap of the toggle 110, the circle can move to the right, which indicates that the permission is on, i.e., granted. In some cases, the toggle 110 can be swiped to change the permission setting. In the illustrated example, the current permission settings for the resources are shown as granted. A user can change the permission of a particular resource using the toggle 110 while viewing the number of times Application 1 has accessed the particular resource).
10. Regarding claim 5 Schieman teaches the method, wherein the first access record further comprises access data of accessing K pieces of device permission of the first electronic device, and K is a positive integer; and the first prompt in the first interface further comprises K icons, and the K icons respectively indicate that the K pieces of device permission are accessed (Figs.1-3 shows accessing K pieces of device permission of the first electronic device . Para:0011-0013 teaches the user interface 100 includes the resource access information of Application 1 with respect to different resources. In the illustrated example, the user interface 100 shows that in a particular time period, e.g., the last 7 days, Application 1 has accessed the camera resource 33 times, the contacts resource 78 times, the location resource 89 times, and the microphone resource 47 times. The user interface 100 also includes one or more user interface objects associated with each resource for Application 1. In the illustrated example, the user interface objects are toggles, e.g., toggle 110. The toggle 110 can be displayed as a circle on a bar. The toggle 110 can be tapped or otherwise actuated to change the permission setting. In one example, the circle appears on the left of the toggle 110, which indicates that the permission is off, i.e., denied. In response to receiving user input corresponding to a tap of the toggle 110, the circle can move to the right, which indicates that the permission is on, i.e., granted. In some cases, the toggle 110 can be swiped to change the permission setting. In the illustrated example, the current permission settings for the resources are shown as granted. A user can change the permission of a particular resource using the toggle 110 while viewing the number of times Application 1 has accessed the particular resource).
11. Regarding claim 11 Schieman teaches the method, wherein the method further comprises: receiving, by the first electronic device, a fourth operation; and displaying, by the first electronic device, a second control in response to the fourth operation, wherein the second control is used to manage access of the second electronic device to the device permission of the first electronic device, or displaying, by the first electronic device, a third control in response to the fourth operation, wherein the third control is used to manage access of different applications on the second electronic device to the device permission of the first electronic device (Figs.1-3 and Para:0011-0012 teaches accesses to a resource on a communication device can be monitored. For example, a resource management application on a device can monitor a number of accesses to a resource made by one or more applications over a monitoring period. In some cases, a user interface can be outputted on the device to display the information associated with one or more resource accesses by an application. In some cases, a user can further review detailed information of the resource access, e.g., the time, the duration, and the location of the device when the access is made through the same or different user interfaces. In some cases, one user interface can be outputted to show the resource accesses information collected by the resource management application and provide a user interface object for the user to set permissions for resource access. Examples of the user interface object can include an icon, a dialogue box, or any other user interface objects that enable the user to make a selection through a user interface action. Examples of the user interface action can include tapping, swiping, clicking, touching, etc. Para:0013 teaches a screen shot of an example graphic user interface 100 that outputs resource access information for one application according to an implementation. As shown in FIG. 1, the user interface 100 includes the resource access information of Application 1 with respect to different resources. In the illustrated example, the user interface 100 shows that in a particular time period, e.g., the last 7 days, Application 1 has accessed the camera resource 33 times, the contacts resource 78 times, the location resource 89 times, and the microphone resource 47 times. The user interface 100 also includes one or more user interface objects associated with each resource for Application 1. In the illustrated example, the user interface objects are toggles, e.g., toggle 110. The toggle 110 can be displayed as a circle on a bar. The toggle 110 can be tapped or otherwise actuated to change the permission setting. In one example, the circle appears on the left of the toggle 110, which indicates that the permission is off, i.e., denied. In response to receiving user input corresponding to a tap of the toggle 110, the circle can move to the right, which indicates that the permission is on, i.e., granted. In some cases, the toggle 110 can be swiped to change the permission setting. In the illustrated example, the current permission settings for the resources are shown as granted. A user can change the permission of a particular resource using the toggle 110 while viewing the number of times Application 1 has accessed the particular resource).
12. Regarding claim 12 Carrara teaches the method, wherein after the receiving, by the first electronic device, the first operation, the method further comprises: querying, by the first electronic device in the first time period, an access record of accessing device permission of another electronic device by the first electronic device in the first time period, to obtain a second access record, wherein the first time period is before the first operation is received, and the second access record comprises access data of accessing second device permission of a third electronic device by the first electronic device; wherein the first interface further comprises a second prompt, the second prompt is determined based on the second access record, and the second prompt indicates that the first electronic device accesses the second device permission of the third electronic device (Fig.5 and Para:0101-0105 teaches At 535, after the installation of the application 402 at 530, the first mobile device 100 executes the application 402. This may be performed in response to a user's direction to execute the application, by selecting an associated application icon, for example. During execution of the application 402, an attempt to access a computing resource on the first mobile device 100 is made by the application 402. In the example scenario described above, this may involve the mobile device 100 accessing a camera API that the `CycleNation` application provides to capture photographs of features on a cycling route. At 540, the first mobile device 100 determines that the application 402 is not configured to access the computing resource, in response to the attempt made at 535. It may do this, for example, by examining the installation manifest associated with the application 402, and determining that the installation manifest fails to identify the computing resource as a computing resource that the application 402 will access on the first mobile device 100 when the application is executed. In the example scenario described above, the installation manifest for the `CycleNation` application does not list the camera API as a computing resource that the application will access when the application is executed. This resulted in a permission request not being displayed for the computing resource during installation. For example, in the `CycleNation` example scenario, the application developer may have added the camera functionality to the application, and uploaded it to the application server without making a corresponding update to the installation manifest. As a further example, additional functionality may be provided by an application, as a result of the application developer adding new features to an application 402 or because a new computing resource is being made available on certain mobile devices. Para:0106-0108 teaches At 545, the first mobile device 100 displays a permission request to allow the application 402 to access the computing resource that the application 402 is attempting to access at 535, during execution of the application 402. This permission request may be displayed to a user in a user interface of the first mobile device 100. FIG. 6B illustrates an example visual output displaying the `CycleNation` application's permission request 604c for the camera API on `Bob's Device` 600. When viewing the permission request, a user may allow 610' or deny 612' the `CycleNation` application access to the camera API. At 550, the first mobile device 100 transmits data that notifies the application server 268 of the attempt to access the computing resource by the application 402 made at 535, when the application 402 was not configured to access the computing resource as determined at 540. This data is then received by the application server 268 at 555. At 552, the application 402 may be allowed access to the computing resource if the permission request displayed at 545 is accepted by the user or the access may be otherwise denied).
13. Regarding claim 13 Carrara in view of Schiema teaches the method, wherein the device permission of the first electronic device comprises camera permission, microphone permission, location permission, contact permission, and media and file permission (Carrara: Figs.6A-B, 7 and Pra:0051 the device permission comprises camera permission, microphone permission, location permission, contact permission, and media and file permission.
Schieman: Fig.1 and Para:0008)..
14. Regarding claim 14 Schiema teaches the method, wherein the first operation is an operation of sliding downward from a top right side of a screen of the first electronic device, and the first interface is a control center interface of the first electronic device (Schiema :Fig. 1 and Para:0013 teaches the first operation is an operation of sliding from a top right side of a screen of the first electronic device).
15. Regarding claim 15 Carrara an electronic device, comprising: a screen; a memory storing instructions; and at least one processor in communication with the screen and with the memory, the at least one processor configured, upon execution of the instructions, to perform the following steps: receiving, by a first electronic device, a first request from a second electronic device, the first request requesting to access first device permission of the first electronic device; in response to the first request, allowing, by the first electronic device, the second electronic device to access the first device permission and displaying a first icon in a status bar, the first icon indicating that the first device permission is accessed; receiving, by the first electronic device, a first operation; and displaying, by the first electronic device, a first interface in response to the first operation, the first interface comprising a first prompt, and the first prompt comprising the first icon (see, the rejection for claim 1).
16. Regarding claim 16 Carrara the method, wherein the method further comprises: receiving, by the first electronic device, a second operation on the first prompt; and displaying, by the first electronic device, a first permission list in response to the second operation, wherein the first permission list comprises first information, and the first information indicates that the first device permission is accessed by the second electronic device (see, the ejection for claim 2).
17. Regarding claim 17 Carrara the method, wherein the method further comprises: receiving, by the first electronic device, a third operation on the first information; and displaying, by the first electronic device, a first control in response to the third operation, wherein the first control is used to manage access of the second electronic device to the first device permission (see, the rejection for claim 3).
18. Regarding claim 18 Carrara the method, wherein after the receiving, by the first electronic device, the first operation, the method further comprises: querying, by the first electronic device, an access record of accessing device permission of the first electronic device in a first time period to obtain a first access record, wherein the first time period is before the first operation is received, and the first access record comprises first access data of accessing the first device permission by the second electronic device; and the displaying, by the first electronic device, the first interface, wherein the first interface comprises the first prompt comprises: displaying, by the first electronic device, the first interface based on the first access record, wherein the first interface comprises the first prompt, and the first icon comprised in the first prompt is determined based on the first access data (see, the rejection for claim 4).
19. Regarding claim 19 Carrara the method, wherein the first access record further comprises access data of accessing K pieces of device permission of the first electronic device, and K is a positive integer; and the first prompt in the first interface further comprises K icons, and the K icons respectively indicate that the K pieces of device permission are accessed (see, the rejection for claim 5).
20.Claims 6-7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Carrara (US Pub.No.2012/01317565) in view of Schieman (US Pub.No.2017/0235469) as applied to claims 1, 5 above and further in view of Gao (US Pub.No.2023/0195298).
21. Regarding claim 6 Carrara in view of Schieman teaches all the above claimed limitations but fails to teach the method, wherein the first icon and the K icons comprised in the first prompt are displayed in a folded manner based on a first priority sequence; the first priority sequence indicates a priority sequence of the device permission of the first electronic device, a higher priority of device permission in the first priority sequence indicates that an icon that indicates that the device permission is accessed is displayed at a higher level in the first interface, and an icon displayed on an upper layer partially blocks an icon displayed on a lower layer; and the first prompt further comprises an identifier of a visitor of device permission corresponding to an icon displayed at a highest level in the first prompt .
Gao teaches the first icon and the K icons comprised in the first prompt are displayed in a folded manner based on a first priority sequence; the first priority sequence indicates a priority sequence of the device permission of the first electronic device, a higher priority of device permission in the first priority sequence indicates that an icon that indicates that the device permission is accessed is displayed at a higher level in the first interface, and an icon displayed on an upper layer partially blocks an icon displayed on a lower layer; and the first prompt further comprises an identifier of a visitor of device permission corresponding to an icon displayed at a highest level in the first prompt (Para:0061-0064 teaches the user selects the first function permission from the plurality of function permissions (as such, the user selected first device function or the device permission is considered as the highest prioritized function or permission herein). Therefore, the permission setting apparatus may cancel display of the plurality of other function permissions and display the first identifier in the area in which the first control is located, so as to keep the plurality of function permissions covering icons on the desktop and make it convenient for the user to select an icon on the desktop. The first identifier is displayed in the area in which the first control is located to prompt the user that the first function permission has been selected, and the first function permission may be quickly set for an application program by an input to an icon and the first control on the desktop).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify the teachings of Carrara in view of Schieman to include a higher priority of device permission in the first priority sequence indicates that an icon that indicates that the device permission is accessed is displayed at a higher level in the first interface, and an icon displayed on an upper layer partially blocks an icon displayed on a lower layer; and the first prompt further comprises an identifier of a visitor of device permission corresponding to an icon displayed at a highest level in the first prompt, as taught by Gao in such a setup the user selects different options from the M options, display forms of icons displayed in the area in which the first control is located may be different, to help the user distinguish selected function permissions, making it convenient for the user to quickly set a function permission (para:0065).
22. Regarding claims 7 and 20 Carrara in view of Schieman teaches all the above claimed limitations but fails to teach the method, wherein the method further comprises: detecting, by the first electronic device, that the second electronic device ends accessing the first device permission; and canceling, by the first electronic device, the displaying of the first icon in the status bar .
Gao teaches the method, wherein the method further comprises: detecting, by the first electronic device, that the second electronic device ends accessing the first device permission; and canceling, by the first electronic device, the displaying of the first icon in the status bar (Para:067 and Para:0078-0080 teaches ending accessing permission and canceling, the display).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify the teachings of Carrara in view of Schieman to include detecting, by the first electronic device, that the second electronic device ends accessing the first device permission; and canceling, by the first electronic device, the displaying of the first icon in the status bar as taught by Gao, in such a setup it will be notified that the app has finished using the feature.
23. Claims 8-10 are rejected under 35 U.S.C. 103 as being unpatentable over Carrara (US Pub.No.2012/01317565) in view of Schieman (US Pub.No.2017/0235469) as applied to claim 7 above and further in view of Mallozzi (US Pub.No.2016/0191534).
24. Regarding claim 8 Carrara in view of Schieman teaches all the above limitations but fails to teach the method, wherein before the canceling, by the first electronic device, the displaying of the first icon in the status bar, the method further comprises: determining, by the first electronic device, that a first access duration in which the second electronic device accesses the first device permission exceeds a first duration.
Mallozzi teaches determining, by the first electronic device, that a first access duration in which the second electronic device accesses the first device permission exceeds a first duration (Para:00132-0134 teaches monitoring the access has exceeded the duration).
25. Regarding claim 9 Carrara in view of Schieman teaches all the above limitations but fails to teach the method, wherein the method further comprises: detecting, by the first electronic device, that the second electronic device ends accessing the first device permission; determining, by the first electronic device, whether a first access duration in which the second electronic device accesses the first device permission exceeds a first duration; when determining that the first access duration does not exceed the first duration, determining, by the first electronic device, a first extended duration based on a difference between the first access duration and the first duration; and continuing, by the first electronic device, to display the first icon in the status bar in a second time period, wherein the second time period is in the first extended duration starting from a moment at which the second electronic device ends accessing the first device permission.
Mallozzi teaches detecting, by the first electronic device, that the second electronic device ends accessing the first device permission; determining, by the first electronic device, whether a first access duration in which the second electronic device accesses the first device permission exceeds a first duration; when determining that the first access duration does not exceed the first duration, determining, by the first electronic device, a first extended duration based on a difference between the first access duration and the first duration; and continuing, by the first electronic device, to display the first icon in the status bar in a second time period, wherein the second time period is in the first extended duration starting from a moment at which the second electronic device ends accessing the first device permission (Figs.5A--B teaches the data structures storing permissions and access request records. The entries of the permission table 344 correspond to permissions for respective applications for accessing device resources. Para:0014-0015 teaches the records table 346 shows the extended time duration permission for “Application 01” accessing the GPS device. Para:00132-0134 teaches monitoring the access has exceeded the duration).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify the teachings of Carrara in view of Schieman to include detecting, by the first electronic device, that the second electronic device ends accessing the first device permission; determining, by the first electronic device, whether a first access duration in which the second electronic device accesses the first device permission exceeds a first duration; when determining that the first access duration does not exceed the first duration, determining, by the first electronic device, a first extended duration based on a difference between the first access duration and the first duration; and continuing, by the first electronic device, to display the first icon in the status bar in a second time period, wherein the second time period is in the first extended duration starting from a moment at which the second electronic device ends accessing the first device permission as taught by Mallozzi, in such a setup it will maintains the access record, which will be useful for compliance and improving data integrity.
26. Regarding claim 10 Carrara in view of Schieman teaches all the above limitations but fails to teach the method, wherein the method further comprises: detecting, by the first electronic device in the second time period, a re-access of the first device permission; continuing, by the first electronic device, to display the first icon in the status bar in a time period of the re-access of the first device permission; determining, by the first electronic device, whether a second access duration of the re-access of the first device permission exceeds the first duration; and when determining that the second access duration exceeds the first duration, canceling, by the first electronic device, displaying of the first icon in the status bar at a moment at which re-access of the first device permission ends; or when determining that the second access duration does not exceed the first duration, determining, by the first electronic device, a second extended duration based on a difference between the second access duration and the first duration; and continuing, by the first electronic device, to display the first icon in the status bar in a third time period, wherein the third time period is in the second extended duration starting from a moment at which the re-access of the first device permission ends.
Mallozzi teaches detecting, by the first electronic device in the second time period, a re-access of the first device permission; continuing, by the first electronic device, to display the first icon in the status bar in a time period of the re-access of the first device permission (Figs.4A-B, 5A-B and Para:0014-0015 teaches the records table 346 shows re-accessing the device permission (GPS) by “Application 01”); determining, by the first electronic device, whether a second access duration of the re-access of the first device permission exceeds the first duration; and when determining that the second access duration exceeds the first duration, canceling, by the first electronic device, displaying of the first icon in the status bar at a moment at which re-access of the first device permission ends; or when determining that the second access duration does not exceed the first duration, determining, by the first electronic device, a second extended duration based on a difference between the second access duration and the first duration; and continuing, by the first electronic device, to display the first icon in the status bar in a third time period, wherein the third time period is in the second extended duration starting from a moment at which the re-access of the first device permission ends (Para:00132-0136 teaches monitoring the access time has exceeded the duration, and displaying the icon in the status bar).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the invention was filed to modify the teachings of Carrara in view of Schieman to include detecting, by the first electronic device in the second time period, a re-access of the first device permission; continuing, by the first electronic device, to display the first icon in the status bar in a time period of the re-access of the first device permission as taught by Mallozzi, in such a setup it will maintains the access record, which will be useful for compliance and improving data integrity.
.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEREENA T CATTUNGAL whose telephone number is (571)270-0506. The examiner can normally be reached Mon-Fri : 7:30 AM-5 PM 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, Lynn Feild can be reached at 571-272-2092. 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.
/DEREENA T CATTUNGAL/Primary Examiner, Art Unit 2431
Prosecution Insights