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 .
Detailed Action
Response to Arguments
Applicant’s arguments filed January 02, 2026 have been fully considered. After further consideration, a new ground(s) of rejection due to Applicant’s amended claim language.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1 – 10 and 12 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Finger (US Pub. No. 2009/0113458 A1) in view of Wilairat (US Pub. No. US2012/0084734 A1) in view of AAPA (Applicant Admitted Prior Art as disclosed in para 0016 of as-filed).
Per claim 1, Finger (US Pub. No. 2009/0113458 A1) suggests an electronic device comprising (reads on exemplary computing environment such as hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like, see Finger para 0098 – 0099): at least one hardware component (reads on hardware resources that are accessed by device drivers through I/O services of the firmware, see Finger Figure 6 blocks 640, 650, 665 and para 0046 – 0050) each having a corresponding hardware channel (reads on I/O services, see Finger para 0005 and 0048 – 0052) for access to a respective one of the at least one hardware component (reads on hardware resources that are accessed by device drivers through I/O services of the firmware, see Finger Figure 6 blocks 640, 650, 665 and para 0046 – 0050) by one or more applications and an operating system (reads on application running on an operating system communicates with an outside device using a driver, see Finger para 0032), the at least one hardware component comprising at least one input device (see Finger para 0102); a memory having stored thereon the one or more applications and the operating system that are configured to access the at least one hardware component, including while the electronic device is in a first locked state (reads on when a system is switched/enabled its device driver messages are passed by the firmware to the associated device, see Finger para 0005, 0046 – 0052 and 0081 – 0082. The Examiner relies upon Finger to teach the general concept of hardware components being enabled when a particular operating system is enabled and disabled when it is not. The Examiner further construes the electronic device being in a first state to be the same as when a specific operating system is enabled, wherein the first state being the first operating system is enabled and others are disabled and the second state being the second operating system is enabled and others are disabled); and at least one processor communicatively coupled to the at least one hardware component and the memory (The Examiner asserts this to be a necessary aspect of implementing a computer, see Finger para 0098 – 0099), the at least one processor executing firmware of the electronic device (reads on the device drivers may be turned on/off at the firmware level, see Finger para 0047 – 0052 and 0081) and is configured to cause the electronic device to: in response to detecting a transitioning of the electronic device to enter into a second state (reads on when a system is disabled, its device driver messages are not passed by firmware to the associated device and when a system is enabled, its device driver messages are passed by the firmware to the associated device, see Finger para 0005 and 0052. The Examiner relies upon Finger to teach the device transitioning from one state to another state and deactivating associated device access through firmware based on the particular state), de-activate a hardware channel associated with each of the at least one hardware component (reads on device driver messages are not passed to the associated device, see Finger para 0005 and 0052), a deactivation of the hardware channel preventing the one or more applications to access the at least one hardware component while the electronic device is in the second locked state (reads on when a system is switched/disabled its device driver messages are not passed by the firmware to the associated device and when a system is switched/enabled its device driver messages are passed by the firmware to the associated device, see Finger para 0005, 0046 – 0052 and 0081 – 0082) while continuing to execute the operating system (reads on the operating system is still running while simultaneously no longer interacting with the hardware of the system, see Finger para 0056, 0057 and 0067 – 0068) in the background mode without access to the at least one hardware component (reads on simultaneously no longer interacting with the hardware of the system, see Finger para 0056, 0057 and 0067 – 0068). The prior art of record is silent on explicitly stating a state being a locked or unlocked state; execute the operating system and the one or more applications while the electronic device is in an unlocked state, the one or more applications having access to the at least one hardware component via the at least one hardware channel; in response to detecting a transitioning of the electronic device from the unlocked state to enter into the first locked state, continue to execute the operating system and the one or more applications in a background mode, the one or more applications continuing to have access to the at least one hardware component via the at least one hardware channel; and the one or more applications in the background mode without access to the at least one hardware component.
[0005] In one embodiment, device drivers of each operating system are routed through I/O services at a firmware level, the firmware unassociated with any specific operating system. When an operating system is disabled, its device driver messages are not passed by the firmware to the associated device. When an operating system is enabled, its device driver messages are passed by the firmware to the associated device.
[0032] When an application running on an operating system communicates with an outside device, such as the shared resource devices shown in FIG. 4, it communicates with the device using a driver written for the operating system in which the application runs. This operating system, through use of its enabled drivers, is able to monitor and respond to inputs from hardware resources. At 210 a first operating system (e.g., an operating system which is part of a software stack 110 of FIG. 1) is run. At 220, a second operating system (e.g., associated with the software stack 112 of FIG. 1) is run simultaneously with the first operating system. The second operating system, as part of its startup, has a portion of its device drivers disabled, such that the second operating system is isolated from communicating with some or all of the hardware devices 160 of the computing device 100. In some embodiments, drivers are disabled which are used by the second operating system to communicate with device hardware 165 (FIG. 1) shared with the first operating system. A minimal set of second operating system drivers (e.g., communication drivers) may be enabled to inform the second operating system when it is to be enabled (e.g., communicate with the shared resources 165 of FIG. 1) to allow the second operating system to restore its drivers to functionality.
[0046] FIG. 6 is a block diagram of an exemplary system 600 with a firmware layer which selectively enables a single running operating system's drivers and disables other running operating system's drivers. A first operating system running on a software stack 610 has associated device drivers 630 which may communicate with hardware resources 665 accessed by both the first and second operating system. A second operating system running on a software stack 612 has associated device drivers 635 which also may communicate with hardware resources 665 accessed by both the first and second operating system. The device drivers 630, 635 (or, in some embodiments, some of the device drivers 630, 635) do not communicate directly with the shared resources 665, but rather communicate with a firmware layer 640 unaffiliated with either operating system instead.
[0047] Firmware 640 may be a software program usually embedded in a hardware device. It is sometimes used to control the specific hardware device in which it is embedded. Other firmware 640 is used at the system level, such as a BIOS used to boot a device on startup. Firmware 640 can stay resident in a computer memory. Here, in an exemplary embodiment, the firmware 640 is loaded when the system (e.g., the system 100) is turned on and is unaffected by which operating system is currently enabled (e.g., has its drivers enabled to talk to the hardware). The firmware 640 then determines which messages to pass to the shared resources.
[0048] In some embodiments, the firmware may have a routine or series of routines--I/O services 650--that allow a single point of entry for device drivers that access shared resources 665. In some embodiments, the I/O services 650 are rudimentary but allow specific drivers to be ported without sacrificing much performance, or without incurring too many fundamental changes.
[0049] Drivers (such as device drivers 330, 335) associated with software stacks (such as the stacks 610, 612), are very operating system specific. Even operating systems created by the same company are probably not compatible. However, drivers of a given operating system may have a common interface. In some systems, drivers may fall into different groups, with each group sharing a common interface. For example, in Windows CE, most drivers fall into four categories: native drivers, stream interface drivers, USB drivers, and NDIS drivers. Each category of driver is accessed in a slightly different way. For example, the stream interface drivers share a common interface, the stream interface; the native drivers share a different common interface, DDI; while the NDIS drivers and the USB drivers have much more idiosyncratic interfaces. However, most if not all of these Windows drivers rely on a layer of code--the module device driver--that can be used across platforms. The module device drive doesn't access the hardware 660 or the shared hardware resources 665 directly, but instead relies on a different code layer, the platform dependent layer, to do so. This platform dependent layer can be modified such that the device drivers all are routed through the firmware I/O services 650. The I/O services may be implemented using simple I/O control (IOCTL) read/write/open/close semantics. Other operating systems may have similar layers that device drivers are routed through prior to reaching an actual device. In such systems the low level layer may be rewritten to force device driver messages through a firmware layer 640.
[0050] The device drivers 630, 635, at various layers, such as, e.g., a the platform dependent layer; a module device driver, and/or an at the application level, may be given an indication of the operating system from which they originate. The firmware 640 may have process such as, e.g., a disk read state machine, that indicates when a certain operating system should be enabled. For example if a disk of a specific format preferably processed by a first operating system (e.g., a HD DVD disk and a Windows CE operating system) is detected by the firmware, the firmware may then indicate to the I/O services 650 to ignore all messages from device drivers associated with the other running operating systems and to send the messages from the designated operating system to the associated hardware devices. Similarly, the firmware layer would then route messages from hardware devices to device drivers of the enabled system, if necessary.
[0051] This enables (i.e., turns on) the designated operating system, as it can now process disk and any other inputs from the system 600. The undesignated operating systems, while still running, are effectively disabled, as they no longer interact with the hardware 660, 665 of the system 600. Further, the turnover from one system to another may happen very quickly. A prior art method of operating a device with multiple operating systems, i.e., rebooting, takes considerably longer.
[0052] In other implementations, multiple I/O services 650, e.g., one for each interface, are present. Each operating system then would modify its device drivers to be routed through designated I/O service 650. The firmware would then signal to the I/O service associated with the enabled operating system to pass on its messages, while the other I/O services would be signaled to block their device driver messages from reaching their designated hardware.
[0056] Here, we are referring to an operating system that is currently isolated from the external hardware devices as `disabled` even though the operating system is still running. When an input is detected by a hardware device that should be processed by the operating system that does not currently have access to the hardware device (that is, is `disabled`), the enabled operating system (the one that has access to the hardware device) dynamically unloads its device drivers, except, optionally, for a small subset of device drivers (the communication drivers, e.g., the inter-OS drivers 334 of FIG. 3) that are used to determine when the operating system should reenable itself. Software stack 810 is shown currently isolated from hardware devices; that is, though running, it can be thought of as disabled. Its memory 820 has only the communication drivers 821 loaded used to signal when it should reenable itself. Software stack 812 is shown currently enabled. Both the communication drivers 823 and other drivers 824 used to communicate with hardware 860 and shared hardware resources, e.g., the shared hardware device drivers 332 (FIG. 3) are loaded. In some embodiments, the resources that the communication drivers speak to (indicated by the dashed line in FIG. 8) are seen as not belonging to the shared hardware resources 865, but rather to the hardware resources 860. When an input is detected by the disabled operating system (e.g., using its communication drivers 821, 823) that indicates that the operating system should enable itself, the operating system dynamically loads its shared resource device drivers 830, 835. In some embodiments, the message to the second operating system to enable itself comes directly from a hardware device, e.g., the disk id detector 475 (FIG. 4).
[0057] In some embodiments, when switching hardware control from a first enabled operating system (such as OS/2 817) to a second disabled operating system (such as OS/1 815) the operating system relinquishing control instigates the enablement of the operating system gaining control; i.e., it passes the baton. In such a case an enable message 839 may be passed from a communication driver 823 associated with the operating system relinquishing control (e.g., OS/2 817) through hardware resources 860 with a corresponding message 838 passed from the hardware resources 860 to a communication driver 821 currently in memory 820 associated with the operating system gaining control, e.g., 815. The operating system 815, recall, is still running, even though currently isolated from the hardware devices, and so is able to process the message 838 passed in using the communication driver(s) 821 without further ado.
[0067] The device drivers 1131, 1136, that access shared resources 1165 may be written to allow the device drivers themselves to release the shared resources upon issuance of a "stop" command, and then resume contacting the shared resources upon receiving a "resume" command. In such a system, the drivers in each operating system that access shared resources--"other drivers" 1131, 1136 may be written (or modified) to support two new function controls, a "stop" control to tell the driver to stop communicating with the hardware; and a "resume" control to tell the driver to start communicating with the hardware. When a stop control message is sent to a driver, the driver will ignore other input from the operating system until a resume control is received. This way, a running operating system 1115, 1117 can be effectively cut off from controlling shared hardware resources 1165 associated with a computing device 1100, without otherwise disabling the operating system 1115, 1117. These controls may be implemented using an IO Control (IOCTL) call, a "DeviceIOControl" call, a similar call, or a combination. When a device driver relinquishes control of a device with a stop command, the device driver should leave the device in an agreed-upon state to gracefully hand-off control to the next operating system device driver.
[0068] An operating system cannot be completely cut off from the computing device world. It needs to be able, at a minimum, to receive a signal that it should enable itself, i.e., turn on its device drivers to communicate with the shared hardware resources 1165. In some embodiments, when control switches from one operating system to another, a set of drivers, the "communication drivers" 1132 1137 are not switched off when switching hardware control from a first enabled operating system (such as OS/2 1117) to a second disabled operating system (such as OS/1 1115). An enable message 1139 is passed from an operating system relinquishing control through a communication driver/drivers 1137 through hardware resources 1160. A corresponding message 1138 is passed from the hardware resources 1160 to a non-disabled communication driver 1132 to the operating system (e.g., 1115) that is gaining control. The operating system 1115, recall, is still running, even though currently disabled, and so is able to process the message 1138 passed in using the communication driver(s) 1132 without further ado.
[0081] A portion of the device drivers may be turned on and off at a firmware 1440 level. Firmware 1440 may be a software program usually embedded in a hardware device. In an exemplary embodiment, the firmware 1440 is loaded when the system (e.g., the system 1400) is turned on and is unaffected by which operating system is currently enabled (e.g., has its drivers enabled to talk to the hardware). In some embodiments, the firmware may have a routine or series of routines, I/O services 1450, that allow a single point of entry for device drivers that access shared resources 1465. A portion of the device driver messages may be sent 1438, 1439 to the firmware layer 1440 rather than directly to the shared resources 1465. The firmware layer then may determine which messages to send to the shared resources 1465; e.g., the enable operating system has its messages sent on to their intended devices, while the disabled operating system(s) have their messages blocked.
[0082] Some operating systems may, when switching control, unload and load a portion of their device drivers, may have the device drivers turn themselves off and on, and may have a portion of the drivers blocked at a firmware level. The specific method that is used for an individual device driver may depend on operating system, the specific nature of the device the driver is for, the computing device that the driver device is embedded in, and so on. This way, the, e.g., fastest, or most convenient, or most easily developed method can be used for any given driver, driver grouping, or operating system.
[0102] The input device(s) 1850 may be a touch input device, such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device, that provides input to the computing environment 1800. For audio, the input device(s) 1850 may be a sound card or similar device that accepts audio input in analog or digital form, a CD-ROM, DVD, HD/DVD, or Blu-ray optical disk reader that provides audio and/or video samples to the computing environment 1800. The output device(s) 1860 may be one or more of a display, printer, speaker, video screen, CD-writer, or another device that provides output from the computing environment 1800.
[0104] Computer-readable media are any available media that can be accessed within a computing environment 1800. By way of example, and not limitation, with the computing environment 1800, computer-readable media include memory 1820, storage 1840, communication media (not shown), and combinations of any of the above.
[0106] The technologies of any example described herein can be combined with the technologies of any one or more other examples described herein.
Wilairat (US Pub. No. 2012/0084734 A1) suggests
a state being a locked (reads on the computing device being in a locked state in which the user has an access level associated with access to less than all resources on the computing devices, see Wilairat Figure 4 and para 0003, 0026 – 0027, 0030 and 0044) or unlocked state (reads on the computing device being in an unlocked state in which the user has an access level associated with access to most or all resources on the computing devices, see Wilairat Figure 4 and para 0003 and 0026 – 0027, 0030 and 0044); execute the operating system and the one or more applications (reads on when executing the unlocked state with full access to all resources on a computing device are available, see Wilairat para 0027, 0044 and Figure 8, Figure 4 block 440) while the electronic device is in an unlocked state (see Wilairat para 0027, 0044 and Figure 8, Figure 4 block 440), the one or more applications having access to the at least one hardware component via the at least one hardware channel (reads on the messaging application receiving communication which necessarily involves the application having access to at least one hardware component via at least one hardware channel, see Wilairat Abstract, para 0003, 0018, 0030 and 0049 – 0050 and Figure 4 and Figure 8); in response to detecting a transitioning of the electronic device from the unlocked state to enter into the first locked state (see Wilairat Figure 4), continue to execute the operating system and the one or more applications in a background mode, the one or more applications continuing to have access to the at least one hardware component via the at least one hardware channel (reads on the messaging application running on the operating system that receives a messaging event that required use of a hardware component in order to receive the message, see Wilairat para 0049 and 0052 – 0053 and Figure 6).
[abstract]A multiple-access-level lock screen system allows different levels of functionality to be accessed on a computing device. For example, when a device is in a locked state, a user can select (e.g., by making one or more gestures on a touchscreen) a full-access lock screen pane and provide input that causes the device to be fully unlocked, or a user can select a partial-access lock screen pane and provide input that causes only certain resources (e.g., particular applications, attached devices, documents, etc.) to be accessible. Lock screen panes also can be selected (e.g., automatically) in response to events. For example, when a device is in a locked state, a messaging access lock screen pane can be selected automatically in response to an incoming message, and a user can provide input at the messaging access lock screen pane that causes only a messaging application to be accessible.
[0003] Technologies described herein relate to providing access to computing devices for certain tasks without unnecessarily compromising security or privacy. In examples described herein, a multiple-access-level lock screen system allows different levels of functionality to be accessed on a computing device. Different lock screen panes provide access to different levels of functionality on the device. For example, when a device is in a locked state, a user can select (e.g., by making one or more gestures on a touchscreen) a full-access lock screen pane and provide input that causes the device to be fully unlocked, or a user can select a partial-access lock screen pane and provide input that causes only certain resources (e.g., particular applications, attached devices, documents, etc.) to be accessible. Lock screen panes also can be selected (e.g., automatically) in response to events. For example, when a device is in a locked state, a messaging access lock screen pane can be selected automatically in response to an incoming message, and a user can provide input at the messaging access lock screen pane that causes only a messaging application to be accessible.
[0020] In any of the examples described herein, a locked state can be any state of a computing device in which the functionality accessible to a user is limited to interacting with a lock screen and providing user input to exit the locked state. Depending on the input provided by the user, the computing device may or may not exit the locked state in response to the user input. For example, a user can interact with a computing device in a locked state by selecting a lock screen pane and providing a password that causes the computing device to exit the locked state and enter an unlocked state. If the password is incorrect, the computing device can provide feedback (e.g., visual feedback) to indicate that the password is incorrect while remaining in a locked state. A computing device in an unlocked state can provide a user with access to all resources on the computing device, or less than all resources on the computing device. A computing device that exits a locked state can enter an unlocked state or some other state. For example, a computing device can enter a power-off state from a locked state when a user presses a power-off button on the device.
[0024] In any of the examples described herein, a lock screen can include any visual information that indicates that a device is in a locked state. Typically, a lock screen is displayed on a touchscreen or other display of a computing device when the computing device is in a locked state. Although described as a lock screen, the visual information in a lock screen need not occupy the entire screen area of a display device. A lock screen may occupy all of a display area or only part of a display area, or a lock screen may be presented as an overlay (e.g., a partially transparent overlay) on top of other visual information. For example, if a collection of images is displayed on a touchscreen of a computing device, and the computing device subsequently enters a locked state (e.g., when the device has been idle for a period of time), a lock screen can be presented as a partially transparent overlay on top of the displayed images.
[0025] In any of the examples described herein, a lock screen can have plural lock screen panes, which can be associated with different access levels. Lock screen panes and access levels are described in further detail in other examples herein.
Example 6
Exemplary Access Level
[0026] In any of the examples described herein, an access level is associated with one or more resources (e.g., applications, documents, etc.) that can be accessed via a computing device. Different lock screen panes are typically associated with different access levels. For example, a lock screen pane can be associated with an access level that allows access to most or all resources accessible via a computing device, or a lock screen pane can be associated with an access level that allows access to a smaller number of resources. Lock screen panes are described in further detail in other examples herein.
[0027] In practice, an access level can be represented in any number of ways (e.g., in a data store that stores information indicating which resources are accessible at particular access levels), and can be associated with any number of resources of any type. For ease of illustration, some access levels are described in examples herein as "Access Level 1," "Access Level 2," etc. Such labels do not necessarily imply a hierarchical or sequential relationship between access levels, although such relationships may exist in practice. For example, an access level labeled as "Access Level 1" can be associated with full access to all resources on a computing device, an access level labeled as "Access Level 2" can be associated with access to less than all resources on the computing device, and an access level labeled as "Access Level 3" can be associated with a single resource (e.g., a single application) of the resources associated with "Access Level 2." Alternatively, "Access Level 1", "Access Level 2" and "Access Level 3" can each be associated with different, individual resources. Access levels also can be labeled and/or relate to one another in other ways. For example, access levels can be labeled as "Full Access," "Enhanced Access" and "Basic Access," where "Full Access" provides access to all functionality, "Enhanced Access" provides access to most, but not all functionality, and "Basic Access" provides access to basic functionality, such as the ability to make phone calls on a smartphone.
[0028] Described techniques and tools can use any number of access levels, and access levels can provide access to any number of resources. The number of access levels and the resources associated with access levels can be adjustable (e.g., based on user settings).
Example 7
Exemplary Lock Screen Pane
[0029] In any of the examples described herein, a lock screen pane can be any visual information in a lock screen associated with an access level. In examples described herein, a lock screen comprises two or more lock screen panes, and each lock screen pane is associated with a different access level.
[0030] Typically, lock screen panes are selectable. Lock screen panes can be selected in response to user input (e.g., touchscreen input). For example, starting from an initial lock screen pane (e.g., a default lock screen pane that is displayed when a computing device enters a locked state) associated with a first access level, a user can use touchscreen gestures (e.g., gestures to the right or to the left) or other input to select other lock screen panes associated with other access levels. Lock screen panes also can be selected in response to events (e.g., an incoming text message). For example, a computing device in a locked state can display a lock screen pane associated with an access level that permits access only to a messaging application when a new message is detected. Lock screen panes also can be selected in response to a combination of user input and events. For example, a lock screen can have a lock screen pane that becomes available for selection when a particular event occurs, but is not selected automatically when the event occurs. A user can then select the newly available lock screen pane by, for example, using gestures on a touchscreen to navigate to the newly available lock screen pane.
[0031] Lock screen panes can be visible one at a time, or more than one at a time, in a display area. For example, a user can pan through different lock screen panes that are displayed one at a time in a display area, or a user can select (e.g., with a tap gesture on a touchscreen) a lock screen pane that is displayed along with other lock screen panes at the same time in a display area. Lock screen panes may not always be visible when a computing device is in a locked state.
[0032] The visual information in a lock screen pane can occupy all of a display area or only part of a display area, or a lock screen pane may be presented as an overlay (e.g., a partially transparent overlay) on top of other visual information. For example, if a collection of images is displayed on a touchscreen of a computing device in an unlocked state, and the computing device subsequently enters a locked state (e.g., when the device has been idle for a period of time), a lock screen pane can be presented as a partially transparent overlay on top of the displayed images.
[0033] Described techniques and tools can use lock screens with any number of lock screen panes in any configuration, and lock screen panes can be associated with any number of access levels.
[0044] According to the example shown in FIG. 4, a computing device in a locked state can be in a locked state 410 in which a partial-access lock screen pane is displayed, or a locked state 420 in which a full-access lock screen pane is displayed. The device can switch between the lock screen states depending on, for example, user input or events that cause a lock screen pane to be selected. From locked state 410, if the computing device is unlocked (e.g., in response to a user's entry of a correct password at the partial-access lock screen pane), the computing device enters a partial-access unlocked state 430, in which the computing device is unlocked but only allows access to a subset of resources on the computing device. From locked state 420, if the computing device is unlocked (e.g., in response to a user's entry of a correct password at the full-access lock screen pane), the computing device enters a full-access unlocked state 440, in which the computing device is unlocked but and allows access to a full set of resources (i.e., more resources than the subset of resources in partial-access unlocked state 430).
1. A computer-implemented method comprising: receiving selection input comprising one or more gestures on a touchscreen of a computing device; responsive to the selection input, selecting a first lock screen pane of plural lock screen panes in a multiple-access-level lock screen user interface, each of the plural lock screen panes associated with a different one of plural access levels, each of the plural access levels having corresponding different functionality on the computing device; and displaying the first lock screen pane in response to the selecting.
PNG
media_image1.png
556
790
media_image1.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the computing hardware access teachings of the prior art of record by integrating the requirement to have a locked and unlocked state to limit computing hardware access to realize the instant limitations. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141, are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that switching between the various locked states of Wilairat that provide different computing device access using the firmware based control of Finger would have been obvious since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized the results of the combination were predictable. The motivation to combine the references is applied to all dependent claims under this heading.
AAPA suggests
while continuing to execute the one or more applications in the background mode without access to the at least one hardware component (reads on when in a locked state certain applications operate in the background and continue to operate and access the hardware components, see AAPA para 0016).
[0016] An electronic user device often ships with certain applications pre-installed thereon. Additionally, a user of the electronic device will typically install many different applications on the electronic device and provide consent to the installed application(s) to use various permissions, including access to hardware components of the electronic device, such as the camera, microphone, storage, WiFi and/or Bluetooth adapters, etc. Certain pre-installed and user-installed applications operate in the background and continue to operate and access the hardware components (i.e., via a hardware channel) even when the electronic device is placed in a locked screen state (i.e., a display screen state in which access to certain operational features and applications are prevented unless/until the user enters a login credential or otherwise provides a required authentication to unlock the device). Over time, a device user loses track of which applications can access the device hardware in the background. As a result, these applications, including artificial intelligence (AI) based applications such as user assistance applications, continue to be able to monitor the device environment and capture or record events occurring with and around the device. The hardware channel becomes vulnerable, as the installed application has permission to access and can use the hardware channels anytime and anywhere since the user has provided consent during installation or the device was shipped with the application having hardware access pre-set, as a default setting. Such access to the hardware channels presents a security threat to the device and the user.
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the computing hardware access teachings of the prior art of record by integrating the requirement to have certain applications continue hardware component access in the background during a locked state to realize the instant limitations. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that implementing the ability to have certain applications continue hardware component access in the background during a locked state within the system of the prior art of record would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such features into similar systems, resulting in an improved system that uses all available known in the art techniques to selectively restrict and allow hardware components during locked states. The motivation to combine the references is applied to all claims below this heading.
Per claim 2, the prior art of record further suggests transition into a secure authentication access mode that requires verification of an authentication input to trigger reactivation of (reads on an event-triggered lock screen can receive an expected input to authenticate a user and after authentication the user can access the computing device’s hardware and software at an access level that corresponds to the selected lock screen pane, see Wilairat para 0051 and 0058 – 0061 and Finger para 0005 and 0048 – 0052) the hardware channel (reads on I/O services, see Finger para 0005 and 0048 – 0052) and restore access to (reads on when enabled, device driver messages are passed by firmware to the associated device utilizing specific I/O services, see Finger para 0005 and 0048 – 0052) the respective at least one hardware component (reads on hardware resources that are accessed by device drivers through I/O services of the firmware, see Finger Figure 6 blocks 640, 650, 665 and para 0046 – 0050), including to receive input from (reads on receiving unlock input, see Wilairat para 0061) the at least one input device (reads on associated with any number of resources of any type, see Wilairat para 0027 – 0028); monitor for receipt of an access authentication input to unlock the electronic device (reads on the system receives the unlock input used to authenticate a user and determines whether the unlock input matches expected unlock input, see Wilairat para 0059 – 0061); and in response to verification of the access authentication input (reads on when the unlock input matches expected unlock input the system exits the locked state and enters an unlocked state, see Wilairat para 0061): reactivate (reads on when a system is switched/enabled its device driver messages are passed by the firmware to the associated device, see Finger para 0005, 0046 – 0052 and 0081 – 0082) the hardware channel (reads on I/O services, see Finger para 0005 and 0048 – 0052) to provide access to (reads on when a system is switched/enabled its device driver messages are passed by the firmware to the associated device, see Finger para 0005, 0046 – 0052 and 0081 – 0082) the at least one hardware component (reads on hardware resources that are accessed by device drivers through I/O services of the firmware, see Finger Figure 6 blocks 640, 650, 665 and para 0046 – 0050) and receive input from (reads on when a system is switched/enabled its device driver messages are passed by the firmware to the associated device, see Finger para 0005, 0046 – 0052 and 0081 – 0082) the at least one input device (reads on associated with any number of resources of any type, see Wilairat para 0027 – 0028); and unlock the electronic device (reads on exits the locked state and enters an unlocked state, see Wilairat para 0061) .
Per claim 3, the prior art of record further suggests wherein the at least one hardware component comprises at least one of a microphone, a speaker, a camera, a biometric scanner, a storage device, and each wireless connection adapter/component (reads on associated with any number of resources of any type, see Wilairat para 0027 – 0028 and 0094).
Per claim 4, the prior art of record further suggests further comprising at least one firmware component associated with operation of a corresponding hardware channel (reads on hardware resources that are accessed by device drivers through I/O services of the firmware, see Finger Figure 6 blocks 640, 650, 665 and para 0046 – 0050), wherein to deactivate (reads on when a system/device is disabled, its device driver messages are not passed by firmware to the associated device and when a system is enabled, its device driver messages are passed by the firmware to the associated device, see Finger para 0005 and 0052) the hardware channel the at least one processor is configured to de-activate a corresponding firmware component for each hardware channel (reads on the device drivers may be turned on/off at the firmware level, see Finger para 0047 – 0052 and 0081).
Per claim 5, the prior art of record further suggests wherein the at least one processor is further configured to cause the electronic device to: monitor for receipt of an exception trigger that is pre-established to temporarily override the de-activation of the hardware channel (reads on determine if a phone-related event was indicated and in response to the indicator the selected lock screen pane associated with an access level only having corresponding functionality associated with the event is presented, see Wilairat para 0049 – 0050); and in response to receipt of the exception trigger (reads on in response to the phone-related event occurring and the unlock input authenticated, see Wilairat para 0049 – 0051 and 0061): transition the electronic device to an intermediate locked state that enables device operations associated with the exception trigger (reads on entering an unlock state associated with an access level enabling functionality restricted to phone-related functionality, see Wilairat para 00049 – 0051); re-activate at least one hardware channel that is required for completion of one or more device functions corresponding to the exception trigger (reads on when a system is switched/enabled its device driver messages are passed by the firmware to the associated device, see Finger para 0005, 0046 – 0052 and 0081 – 0082); and enable completion of the one or more device functions associated with the exception trigger (reads on entering an unlock state associated with an access level enabling functionality restricted to phone-related functionality, see Wilairat para 00049 – 0051).
Per claim 6, the prior art of record further suggests wherein the at least one processor is further configured to cause the electronic device to: monitor for completion of the one or more device functions (reads on receive indicator of event at computing device, see Wilairat Figure 5 block 510. The Examiner asserts it would have been obvious to one of ordinary skill in the art to monitor for the completion of a phone-related event based on the teaching of monitoring for the start of a phone-related event and the general teaching of receiving/monitoring for an indicator of event at computing device, see Wilairat para 0030, 0049 – 0051 and Figure 4 and Figure 5); and reconfigure the electronic device into the second locked state (reads on responsive to indicator, select lock screen associated with access level having corresponding functionality associated with the event and ensuring device driver messages are not passed by the firmware to the associated device, see Finger para 0005, 0046 – 0052 and 0081 – 0082) by de-activating the at least one hardware channel required for completion of the one or more device functions (reads on the device drivers may be turned on/off at the firmware level, see Finger para 0047 – 0052 and 0081).
Per claim 7, the prior art of record further suggests wherein the exception trigger comprises one from a group comprising: receipt of an incoming audio call, wherein the at least one hardware component comprises a microphone that is temporarily re-activated to enable answering the incoming audio call and communicating audio input with the audio call; receipt of an emergency call; and receipt of an audio-video call, wherein the at least one hardware component comprises a microphone and a camera that are temporarily re-activated to enable answering and communicating audio and video input with the audio-video call (see Wilairat para 0030, 0049 – 0051).
Per claim 8, the prior art of record further suggests further comprising: a display device communicatively coupled to the at least one processor (reads on display the default lock screen, see Wilairat Figure 7 block 700 and Finger para 0098 – 0099. The Examiner asserts the combined teachings of the prior art at least imply the computer of the prior art of record has a display device communicatively coupled to the processor in order to display the lock screen); and wherein the at least one processor is configured to: render a lock screen for the first locked state and present the lock screen on the display device, the lock screen comprising a selectable option for transitioning the electronic device from the first locked state to the second locked state (see Wilairat Figure 7 blocks 710, 740, 750); monitor for receipt of a user selection of the selectable option (see Wilairat Figure 7 blocks 750 and 760); and in response to detecting user selection of the selectable option, configuring the electronic device into the second locked state (see Wilairat Figure 7 block 790).
Per claim 9, the prior art of record further suggests wherein the at least one processor is further configured to: render a user interface with a selectable option for activating the second lock state of the electronic device (see Wilairat Figure 7 blocks 710, 740, 750); and in response to receipt of a selection of the selectable option (see Wilairat Figure 7 blocks 710, 740, 750), automatically update a firmware of the electronic device to configure the electronic device to transition to the second locked state at each instance in which a locked state of the electronic device is triggered (reads on when a system is disabled, its device driver messages are not passed by firmware to the associated device and when a system is enabled, its device driver messages are passed by the firmware to the associated device, see Finger para 0005, 0047 – 0052 and 0081).
Per claim 10, the prior art of record further suggests: one or more sensors from among device sensors comprising a gyroscope, an accelerometer, and a barometer (reads on associated with any number of resources of any type, see Wilairat para 0027 – 0028 and 0097); and a communications subsystem comprising at least one interface for connecting the electronic device to one or more networks (see Wilairat para 0093 and 0096); wherein the at least one processor is communicatively connected to each of the one or more sensors and the communications subsystem and is configured to cause the electronic device to (see Wilairat para 0091 – 0097): determine (reads on determine if a phone-related event was indicated and in response to the indicator the selected lock screen pane associated with an access level only having corresponding functionality associated with the event is presented, see Wilairat para 0049 – 0050), in part based on a connectivity of the electronic device to an identified network and sensed inputs received from the one or more sensors (reads on the necessary network identification and sensed inputs in order to receive a phone-related event such as a message or call, see Wilairat para 0049 – 0050), a device context (reads on the device context of receiving a phone-related event, see Wilairat para 0049 – 0050); perform activity recognition by correlating the device context with activity of a device user (reads on determining the device does not have the phone-related devices enabled so automatically displaying the screen that allows for transition to the use of phone-related devices, see Wilairat para 0049 – 0050); and automatically activate the second lock state in response to the activity recognition indicating a user context that falls within a pre-determined set of user contexts that require removal of access by the one or more applications from the at least one hardware component (reads on entering an unlock state associated with an access level enabling functionality restricted to phone-related functionality, see Wilairat para 00049 – 0051).
Claim 12 is analyzed with respect to claim 1.
Claim 13 is analyzed with respect to claim 2.
Per claim 14, the prior art of record further suggests wherein: the at least one hardware component comprises at least one of a microphone, a speaker, a camera, a biometric scanner, a storage device, and each wireless connection adapter/component of the electronic device (reads on associated with any number of resources of any type, see Wilairat para 0027 – 0028 and 0094); and each of the at least one hardware component comprises at least one firmware module associated with operation of a corresponding hardware channel (reads on hardware resources that are accessed by device drivers through I/O services of the firmware, see Finger Figure 6 blocks 640, 650, 665 and para 0046 – 0050), and deactivating the at least one hardware channel comprises de-activating a corresponding firmware module for each of the at least one hardware channel (reads on when a system/device is disabled, its device driver messages are not passed by firmware to the associated device and when a system/device is enabled, its device driver messages are passed by the firmware to the associated device, see Finger para 0005 and 0052).
Claim 15 is analyzed with respect to claim 6.
Claim 16 is analyzed with respect to claim 7.
Claim 17 is analyzed with respect to claim 8.
Claim 18 is analyzed with respect to claim 9.
Claim 19 the computer program product (see Wilairat claim 15 and Finger para 0104 – 0105) is analyzed with respect to claim 12.
Claim 20 is analyzed with respect to claim 15.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Finger in view of Wilairat in view of AAPA in view of Hui (US Pub. No. 2018/0199202 A1).
Per claim 11, the prior art of record suggests the electronic device of claim 1, further comprising: a communications subsystem comprising at least one interface for connecting the electronic device to one or more second devices (see Wilairat para 0093 and 0096). The prior art of record is silent on explicitly stating the one or more second devices comprising a wearable or on-user device; wherein the at least one processor is communicatively connected to the communications subsystem and is configured to cause the electronic device to: receive a lock device input signal from a connected one of the wearable or on-user device, the lock device input signal correlated to a request for entry by the electronic device into the second lock state; and automatically transition the electronic device into the second lock state in response to receiving the lock device input signal.
Hui (US Pub. No. 2018/0199202 A1) suggests
the one or more second devices comprising a wearable or on-user device (reads on a smartphone used as a locking device, see Hui para 0028); wherein the at least one processor is communicatively connected to the communications subsystem and is configured to cause the electronic device to (reads on the mobile device is caused to lock due to the smartphone/locking device, see Hui para 0028): receive a lock device input signal from (reads on the smartphone sends a lock command to the mobile device to put the mobile device in a locked mode, see Hui para 0035 – 0036) a connected one of the wearable or on-user device (reads on a smartphone used as a locking device, see Hui para 0028), the lock device input signal correlated to a request for entry by the electronic device into the second lock state (reads on in response to receiving the lock command the mobile device is now locked awaiting authorization, see Hui para 0068 and Figure 12 blocks 1204 and 1206); and automatically transition the electronic device into the second lock state in response to receiving the lock device input signal (reads on in response to receiving the lock command the mobile device transitions into a limited/restricted access mode, see Hui para 0036 and 0068).
[0027] By utilizing the systems and methods provided herein, once a mobile device is locked to a smartphone or other device (referred to herein for simplicity of explanation as a “locking device”), the locked mobile device can be configured to function normally only when it is connected to its locking device. If the locked mobile device at any time is unable to find its locking device, its functionalities can be partially or completely disabled. For instance, the locked device can be configured such that it cannot be used to answer incoming calls, stream music, and/or perform other functions outside of the presence of its locking device. However, the locked device can in some cases be configured to continue functioning normally with devices that have previously paired with the locked device even without the locking device being present. In sum, embodiments described herein provide for techniques by which a mobile device, without the device that locked it, can have various functions disabled when paired with a new (e.g., not previously connected) device, such as a smartphone that differs from a smartphone that locked the mobile device.
[0028] In various embodiments described herein, a smartphone or other locking device is used as a security token to protect a mobile device, e.g., a Bluetooth device. For instance, a smartphone located with its user can be utilized to protect connected Bluetooth devices from loss. The smartphone itself can also be protected from loss by a separate token, e.g., a token associated with one or more of the connected Bluetooth devices. If one of the connected Bluetooth devices loses connection with its token, here the user's smartphone, the disconnected device will move to disable substantially all of its functionality, thereby rendering it useless to thieves and/or other unauthorized users.
[0029] Further embodiments herein facilitate techniques by which a mobile device user, if so desired, can unlock a locked device by using a computing device having a user interface, an application developed for mobile device security control, and user-defined authentication credentials, as described herein. A device utilized to unlock a locked device in this manner can be the same as the locking device or a different device that has stored thereon the interface, application, and/or other components for mobile device security control as described herein. If a user forgets his or her login credentials (e.g., password, personal identification number (PIN), etc.) for the application, the credentials can be retrieved using a registered email and/or by other means.
[0031] Referring first to Error! Reference source not found. FIG. 1, shown is a system 100 that facilitates mobile device security controls in accordance with various aspects described herein. The system 100 can be implemented by a mobile accessory device (e.g., a Bluetooth headset, communicator, or the like that connects to a smartphone or other device via a wireless communication link) and/or any other wireless communication device for which access controls are desired. The system 100 includes a communication component 110 that connects to a first device (locking device, master device, etc.) via a first wireless communication link. In one example, the first device is a smartphone and/or other device that includes an application, interface, and/or other means for controlling access to the system 100.
[0032] The system 100 further includes a mode selection component 120 that initiates a restricted access mode of the system 100 in response to reception of a lock command from the first device via the communication component 110. In an aspect, the lock command can be sent from the first device via a security control application running on the first device, e.g., by a user of the first device that interacts with the security control application. In response to the lock command, the mode selection component 120 can cause the system 100 to restrict communication with non-trusted or otherwise unknown devices. For instance, the system 100 can maintain a list or other structure indicating respective devices that have previously paired with or connected to the system 100 and may exempt one or more of the indicated devices from the restrictions imposed by the mode selection component 120.
[0033] In the event that a second device connects to the system 100 via the communication component 110 while the system 100 is in the restricted access mode, an authentication component 130 can compare an identity of the second device with respective identities of a group of trusted devices, e.g., as defined by the list or other structure of previously connected devices as described above. In response to this comparison indicating that the identity of the second device is a same identity or a substantially similar identity, based on a defined similarity criterion, to an identity of at least one of the respective ones of the group of trusted devices, a control component 140 can identity the second device as a trusted device and permit communication with the second device. Alternatively, if the second device is not in the group of trusted devices and/or the authentication component 130 is otherwise unsuccessful in attempting to match the identity of the second device with that of at least one of the group of trusted devices, the control component 140 can disable communication by the system 100 with the second device pending receipt of a direct or indirect authorization that permits such communication.
[0034] Turning next to FIGS. 2A-2E, illustrated is a series of example, non-limiting operations that can be performed in connection with a mobile device security lock as described herein. Here, the operations are performed by a smartphone 202 acting as a locking device and an accessory device, here a Bluetooth headset 204, which implements some or all of system 100 as shown in FIG. 1. It should be appreciated, however, that the operations described with respect to FIGS. 2A-2E could be performed by any suitable devices, having any suitable communication functionality, in addition to and/or in place of the devices 202, 204 shown in FIGS. 2A-2E and described below.
[0035] With reference first to FIG. 2A, diagram 200 shows smartphone 202 being initially connected to (paired with) headset 204. Once a connection between smartphone 202 and headset 204 has been established, diagram 200 further shows that smartphone 202 can send a command and/or other signal to headset 204 in order to enable a security lock at headset 204. This command can be initiated, e.g., by an application, an interface (e.g., a device settings interface), and/or other software components executed by smartphone 202. In an aspect, the command can be provided by a user of smartphone 202, who authenticates with an application running on smartphone 202 and/or one or more external entities (e.g., an authentication server, etc.) using a password, personal identification number (PIN), and/or other credentials.
[0036] Once the lock command has been provided and authenticated, the command is received at headset 204, e.g., via a communication component 110. In response to receiving the command, headset 204 can enter a locked (limited access, restricted access, etc.) mode, e.g., via a mode selection component 120. For clarity of illustration, a padlock indicator is provided in FIGS. 2A-2E to illustrate the mode in which headset 202 is operating in the respective drawings.
[0037] Next, as shown by diagram 210 in FIG. 2B, a second smartphone 206 can connect to and/or pair with headset 204. As headset 204 was placed in a locked mode via the lock command shown in diagram 200, headset 204 can determine (e.g., via an authentication component 130) whether second smartphone 206 is a trusted and/or otherwise pre-authorized device. In an aspect, headset 204 can determine whether second smartphone 206 is pre-authorized by checking an identity of second smartphone 206 against a group of previously paired or connected devices, a group of designated trusted devices, and/or other suitable data structures.
[0055] Turning next to FIG. 7, a flow diagram of a process 700 for managing controller features of a mobile communication device is illustrated. At 702, the controller of a security-enabled device, e.g., a Bluetooth device, is paired with a user device (e.g., a smartphone, laptop or desktop computer, etc.). At 704, the security-enabled device initiates one or more security measures in response to whether the controller of the device is locked. If the controller is not locked, the controller features of the device unlock at 706 and the device can operate normally. Otherwise, the process 700 continues to 708 for further security checks.
[0067] Turning next to FIG. 12, illustrated is a flow diagram of a process 1200 for managing access to communication features of a mobile device in accordance with one or more embodiments described herein. At 1202, a system comprising a processor (e.g., system 100 as implemented by a Bluetooth device or other mobile communication device) connects to a trusted device via a first wireless communication link.
[0068] At 1204, the system receives (e.g., via a communication component) a lock command from the trusted device. At 1206, in response to receiving the lock command at 1204, the system transitions (e.g., via a mode selection component 120) from an open access mode of the system to a limited access mode.
[0069] At 1208, the system connects to a non-trusted device via a second wireless communication link while in the limited access mode initiated at 1206. At 1210, the system attempts (e.g., via an authentication component 130) to obtain an authorization for communication by the system with the non-trusted device. At 1212, in response to attempting to obtain the authorization being determined to be unsuccessful, the system prevents (e.g., via a control component 140) the communication with the non-trusted device.
[0092] With regard to the various functions performed by the above described components, devices, circuits, systems, etc., the terms (including a reference to a “means”) used to describe such components are intended to also include, unless otherwise indicated, any structure(s) which performs the specified function of the described component (e.g., a functional equivalent), even if not structurally equivalent to the disclosed structure. In addition, while a particular feature of the disclosed subject matter may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application.
PNG
media_image2.png
1092
724
media_image2.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the device locking teachings of the prior art of record by integrating the remote device locking teachings of Hui to realize the instant limitations. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141, are used to support this conclusion of obviousness. Accordingly, As in Hui, it is within the capabilities of one of ordinary skill in the art to have a remote device issue a lock command to a device capable of having its functions restricted, in a system similar to that of the prior art of record, in order to realize the expected benefit of executing the limited functionality state of the prior art of record using all available technology to prevent unauthorized use of the device. The motivation to combine is applied to all claims under this heading.
Conclusion
A new ground(s) of rejection is presented due to Applicant’s amended claims. 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 extension fee 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 date of this final action.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights