DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In communications filed on 02/23/2026. Claims 1-51 cancelled. Claims 52, 57-58, 62, and 67-68 are amended. Claims 52-71 are pending in this examination.
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. This examination is in response to US Patent Application No. 18/235,094.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. —The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 52-71 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The dependent claims 52, and 62 contain “an algorithmic function of the RSSI”, which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. The specification in paragraph 151 states that implement an algorithm that is a function of RSSI and returns distance, however does not indicate how this algorithm calculates the distance? For the purpose of prosecution examiner interprets that the proximity zone calculation in Harrison application reads on the amended limitation of algorithmic function , please refer to Harrison application [Abstract, ¶¶32-34].
Applicant is kindly requested to show the examiner support in the original disclosure for the new or amended claims. See MPEP 714.02 and 2163.06 (“Applicant should specifically point out the support for any amendments made to the disclosure").
Claims 53-61, and 63-71 do not cure the deficiency of claims 52, and 62 and are rejected under 35 USC 112, 1st paragraph, for their dependency upon claims 52, and 62.
Response to Arguments
Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant's arguments filed 02/23/2026 have been fully considered but they are not persuasive:
Applicant submits on pages 7-8 of remarks filed on 02/23/2026 that Applicant has amended independent claims 52 and 62 to recite, inter alia, the element of "determining an anticipated processing ratio between the private device and the public device to balance processing requirements for executing user commands received from the private device, wherein the anticipated processing ratio is based on an application usage history of a user profile, a device identifier of the private device, and on the distance." None of the cited references teach or suggest such elements.
Examiner respectfully disagrees with applicant argument for claims 52, and 62 filed on 02/23/2026 on pages 7-8 of remarks.
While Harrison discloses this limitation as: [ Abstract, Techniques and tools for controlling public output devices (e.g., public display devices) with client devices over a network. In some examples, a time-limited proximity code is displayed by a public display device, and a client device can provide the code via a public network to verify that the client device is present within a proximity zone and is allowed to control the public display. Once authorized, the client device can provide control data to control visual content on the public display], and [ ¶16, Described techniques and tools can be used to verify a user's presence within a proximity zone and restrict access by distant and/or unauthorized users], and [¶32. In some scenarios, it is desirable to limit access to public output devices to users that are in a local area (e.g., to avoid disruption by intruders at remote locations). As used herein, the term "proximity" is used to describe a measure of closeness (e.g., physical distance) between devices (e.g., the client device 210 and the public output device 220). In the example shown in FIG. 2, the client device 210 is within a proximity zone 290 which also includes the public output device 220. The presence of the client device 210 within the proximity zone 290 indicates that the client device is considered to be close enough to control the public output device 220], and [ ¶34... requiring Bluetooth or local network connections to verify proximity can be inconvenient for some users. ...], and [¶23, The illustrated mobile device 100 can include a controller or processor 110 (e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system 112 can control the allocation and usage of the components 102 in various ways and can provide support for one or more application programs 114. The application programs can include common mobile computing applications (e.g., image-capture applications, email applications, calendars, contact managers, web browsers, messaging applications), or any other computing application], and [ ¶34... requiring Bluetooth or local network connections to verify proximity can be inconvenient for some users. ...], and [¶34].
Harrison does not explicitly disclose, however, Nishiguchi discloses: [ see FIG. 1 and corresponding text for more details, ¶49, the physical machine and the terminal apparatus 3 may be connected to each other wirelessly or by a cable such as a display cable], and [ ¶50, The computer 3 and the physical machine 1 may be connected to each other by a USB (universal serial bus) cable or a communication network, such as the Internet or a LAN (local area network), and transmit or receive information according to a predetermined protocol. The computer 3 may be connected to the physical machine 1 by the LAN. The user of the computer 3 starts the operation environment 2 (hereinafter, referred to as a VM 2) through the physical machine 1. A plurality of VMs 21, 22, 23, . . . that is logically divided is operated on the physical machine 1], and ¶51, The physical machine 1 allocates, to each VM 2, a first processing amount indicating the amount, of hardware resource (hereinafter, referred to as a hardware resource) of the physical machine 1 allocated to each VM 2. In the example illustrated in FIG. 1, the first processing amount indicates a CPU usage rate( equated to balancing processing), which is one of the hardware resources, allocated from the physical machine 1 to each VM 2. As represented by a circle graph, as can be seen from comparison to the VM 22 and the VM 23, the first processing amount allocated to the VM 21 is more than that allocated to the VM 22 and the VM 23. That is, in the circle graph illustrated in FIG. 1, the first processing amount allocated to each VM is hatched. The VM 2 executes an application program (hereinafter, referred to as an application) on each VM 2. A second processing amount varies depending on the kind of application being executed, the number of applications being executed(equated to application usage history, and equated to user command received from private device), or the content of the process of the application being executed (equated to application usage history,, and equated to user command received from private device)], and [¶52], and [ see FIG. 2 and corresponding text for more details, ¶57], and [¶62, The VM management unit 178 monitors the operating states or the stationary states of the VMs 21 to 23, and allocates the hardware resources 10 under predetermined conditions stored in the HD 15. The first processing amount, which is one of the hardware resources 10 allocated, is, for example, a CPU usage rate, an HD usage rate, or a NIC usage rate. The CPU usage rate means the ratio of the time when the VM 2 being operated occupies the CPU 11. For example, when the CPU usage rate is 50%, the corresponding VM 2 occupies the CPU 11 for 0.5 second with respect to 1 second], and [¶¶63-65].
Double Patenting
With regard to the rejection of Claims 52, 57-62, and 67-71 on the basis of non-statutory Double Patenting over claims 1-4, 7-8, 11-14, and 18-19 of Patented Application number 10,749,852. Examiner will maintain the Double Patenting rejection is held in obeyance.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 52-60, and 62-70 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2013/0143651) issued to Harrison (Filed in IDS 08/17/2023) and further in view of US Patent No. (US2010/0251254) issued to Nishiguchi, and further in view of Papakipos (US20170070463).
Regarding claims 52, and 62, Harrison discloses a method comprising: receiving, at a public device, a received signal strength indicator (RSSI) from a private device, wherein the RSSI represents a power of a signal received by the private device [¶34, Although useful, many of the proximity measures described above also have drawbacks. For example, GPS coordinates can be impersonated by intruders that may attempt to gain unauthorized control of a public output device, or by legitimate users that may attempt to circumvent proximity restrictions. As another example, requiring Bluetooth or local network connections to verify proximity can be inconvenient for some users. Accordingly, in any of the described examples other proximity measures (e.g., visual proximity, audio proximity, or some other measure of proximity) can be used. For example, proximity codes displayed at public output devices (e.g., display devices) can be used for determining visual proximity. In some described examples, by displaying a proximity code on a public display device, a system can imply that a user is within a visual proximity zone if the user is able to provide the code, even if the exact position of the client device is not known. The size and shape of a visual proximity zone can vary based on factors such as the size of a displayed code, or the size or viewing angle range of the display itself. As another example, tones or other audio signals (e.g., audible by human ears or not audible by human ears) can be used for determining audio proximity. In some described examples, tones transmitted by a public display device, or a client device can be received by the other device and used to verify audio proximity. The size and shape of an audio proximity zone can vary based on factors such as strength of the audio signal or acoustics of a particular venue. Alternatively, other signals or protocols can be used to verify proximity]; and
Approximating a distance between the public device and the private device, as an algorithmic function of the RSSI [ Abstract, Techniques and tools for controlling public output devices (e.g., public display devices) with client devices over a network. In some examples, a time-limited proximity code is displayed by a public display device, and a client device can provide the code via a public network to verify that the client device is present within a proximity zone and is allowed to control the public display. Once authorized, the client device can provide control data to control visual content on the public display], and [ ¶16, Described techniques and tools can be used to verify a user's presence within a proximity zone and restrict access by distant and/or unauthorized users], and [¶32-34. In some scenarios, it is desirable to limit access to public output devices to users that are in a local area (e.g., to avoid disruption by intruders at remote locations). As used herein, the term "proximity" is used to describe a measure of closeness (e.g., physical distance) between devices (e.g., the client device 210 and the public output device 220). In the example shown in FIG. 2, the client device 210 is within a proximity zone 290 which also includes the public output device 220. The presence of the client device 210 within the proximity zone 290 indicates that the client device is considered to be close enough to control the public output device 220. In any of the examples described herein, proximity can be based on distance from the public output device, context (e.g., co-location of a client device and a public output device within a venue), or some combination of distance and context. For example, a user in a stadium holding a mobile phone at a distance of 150 m from a public display on the opposite side of the stadium can be considered within a proximity zone, while a user outside the stadium but only 100 m from the public display can be considered outside the proximity zone. Proximity can be measured explicitly. For example, the position of a client device can be calculated by GPS or network-based localization. The position of a client device also can be approximated. For example, communication technology (e.g., Bluetooth) with limited range (e.g., 50 m) can be used to determine whether the client device is within the range of a public output device, even if the exact position of the client device is not known…. requiring Bluetooth or local network connections to verify proximity can be inconvenient for some users. ...]; and
determining a radial displacement between the private device and the public device based on a connection strength between the private device and the public device [¶33, In any of the examples described herein, proximity can be based on distance from the public output device, context (e.g., co-location of a client device and a public output device within a venue), or some combination of distance and context. For example, a user in a stadium holding a mobile phone at a distance of 150 m from a public display on the opposite side of the stadium can be considered within a proximity zone, while a user outside the stadium but only 100 m from the public display can be considered outside the proximity zone. Proximity can be measured explicitly. For example, the position of a client device can be calculated by GPS or network-based localization. The position of a client device also can be approximated. For example, communication technology (e.g., Bluetooth) with limited range (e.g., 50 m) can be used to determine whether the client device is within the range of a public output device, even if the exact position of the client device is not known]; and
and determining based on the radial displacement, a predetermined proximity to the public device at which the private device must remain [Abstract, Techniques and tools for controlling public output devices (e.g., public display devices) with client devices over a network. In some examples, a time-limited proximity code is displayed by a public display device, and a client device can provide the code via a public network to verify that the client device is present within a proximity zone and is allowed to control the public display], and [ ¶16, Described techniques and tools can be used to verify a user's presence within a proximity zone and restrict access by distant and/or unauthorized users], and [¶32, In some scenarios, it is desirable to limit access to public output devices to users that are in a local area (e.g., to avoid disruption by intruders at remote locations). As used herein, the term "proximity" is used to describe a measure of closeness (e.g., physical distance) between devices (e.g., the client device 210 and the public output device 220). In the example shown in FIG. 2, the client device 210 is within a proximity zone 290 which also includes the public output device 220. The presence of the client device 210 within the proximity zone 290 indicates that the client device is considered to be close enough to control the public output device 220, and [ ¶34].
determining an anticipated processing ratio between the private device and the public device to balance processing requirements for executing user commands received from the private device, wherein the anticipated processing ratio is based on an application usage history of a user profile, a device identifier of the private device, and on the distance
While Harrison discloses this limitation as: [ Abstract, Techniques and tools for controlling public output devices (e.g., public display devices) with client devices over a network. In some examples, a time-limited proximity code is displayed by a public display device, and a client device can provide the code via a public network to verify that the client device is present within a proximity zone and is allowed to control the public display. Once authorized, the client device can provide control data to control visual content on the public display], and [ ¶16, Described techniques and tools can be used to verify a user's presence within a proximity zone and restrict access by distant and/or unauthorized users], and [¶32. In some scenarios, it is desirable to limit access to public output devices to users that are in a local area (e.g., to avoid disruption by intruders at remote locations). As used herein, the term "proximity" is used to describe a measure of closeness (e.g., physical distance) between devices (e.g., the client device 210 and the public output device 220). In the example shown in FIG. 2, the client device 210 is within a proximity zone 290 which also includes the public output device 220. The presence of the client device 210 within the proximity zone 290 indicates that the client device is considered to be close enough to control the public output device 220], and [ ¶34... requiring Bluetooth or local network connections to verify proximity can be inconvenient for some users. ...], and [¶23, The illustrated mobile device 100 can include a controller or processor 110 (e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system 112 can control the allocation and usage of the components 102 in various ways and can provide support for one or more application programs 114. The application programs can include common mobile computing applications (e.g., image-capture applications, email applications, calendars, contact managers, web browsers, messaging applications), or any other computing application], and [ ¶34... requiring Bluetooth or local network connections to verify proximity can be inconvenient for some users. ...], and [¶34], and [¶23, The illustrated mobile device 100 can include a controller or processor 110 (e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system 112 can control the allocation and usage of the components 102 in various ways and can provide support for one or more application programs 114. The application programs can include common mobile computing applications (e.g., image-capture applications, email applications, calendars, contact managers, web browsers, messaging applications), or any other computing application], and [ ¶34... requiring Bluetooth or local network connections to verify proximity can be inconvenient for some users. ...].
Harrison does not explicitly disclose, however, Nishiguchi discloses: [ see FIG. 1 and corresponding text for more details, ¶49, the physical machine and the terminal apparatus 3 may be connected to each other wirelessly or by a cable such as a display cable], and [ ¶50, The computer 3 and the physical machine 1 may be connected to each other by a USB (universal serial bus) cable or a communication network, such as the Internet or a LAN (local area network), and transmit or receive information according to a predetermined protocol. The computer 3 may be connected to the physical machine 1 by the LAN. The user of the computer 3 starts the operation environment 2 (hereinafter, referred to as a VM 2) through the physical machine 1. A plurality of VMs 21, 22, 23, . . . that is logically divided is operated on the physical machine 1], and ¶51, The physical machine 1 allocates, to each VM 2, a first processing amount indicating the amount, of hardware resource (hereinafter, referred to as a hardware resource) of the physical machine 1 allocated to each VM 2. In the example illustrated in FIG. 1, the first processing amount indicates a CPU usage rate, which is one of the hardware resources, allocated from the physical machine 1 to each VM 2. As represented by a circle graph, as can be seen from comparison to the VM 22 and the VM 23, the first processing amount allocated to the VM 21 is more than that allocated to the VM 22 and the VM 23. That is, in the circle graph illustrated in FIG. 1, the first processing amount allocated to each VM is hatched. The VM 2 executes an application program (hereinafter, referred to as an application) on each VM 2. A second processing amount varies depending on the kind of application being executed, the number of applications being executed (equated to application usage history, and equated to user command received from private device), or the content of the process of the application being executed (equated to application usage history, and equated to user command received from private device))], and [¶52], and [ see FIG. 2 and corresponding text for more details, ¶57], and [¶62, The VM management unit 178 monitors the operating states or the stationary states of the VMs 21 to 23, and allocates the hardware resources 10 under predetermined conditions stored in the HD 15. The first processing amount, which is one of the hardware resources 10 allocated, is, for example, a CPU usage rate, an HD usage rate, or a NIC usage rate. The CPU usage rate means the ratio of the time when the VM 2 being operated occupies the CPU 11. For example, when the CPU usage rate is 50%, the corresponding VM 2 occupies the CPU 11 for 0.5 second with respect to 1 second], and [¶¶63-65].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Harrison by incorporating “information processing apparatus/ physical machine/Server with resource allocation capability”, as taught by Nishiguchi. One could have been motivated to do so in order for the server to incorporate the first processing amount allocated to the VM based on the CPU usage rate and a second processing amount based on what kind of application each VM executes. [ Nishiguchi, ¶51].
Harrison, and Nishiguchi do not explicitly disclose, however, Papakipos discloses determining, a radial displacement between the private device and the public device based on the anticipated processing ratio [ Abstract, in one embodiment, a geographic-positioning component records a first location of a mobile device. The geographic-positioning component determines on a periodic basis a current location of the mobile device. The geographic-positioning component determines whether the current location is outside a geographic region defined at least in part by the first location and a radius, the radius being adjusted from a pre-determined value based on a detected velocity of the mobile device; time of day information; a battery level of the mobile device; or an error of the first location measurement or the current location measurement. If the current location is outside the geographic region, the geographic-positioning component causes a client application of the mobile device to send the current location to a remote server], and [¶29, In particular embodiments, the method for dynamically determining processor duty cycle of a mobile device while continuously accessing geographic position with the mobile device's geographic positioning device need not involve the calculation of a location radius. In particular embodiments, whether with or without hardware or software support for radius calculation, one or more processors of the mobile device may be alerted to transition their states (e.g., from a sleep state to an active state) based on certain conditions being met, as described herein. As an example, the one or more processors of the mobile system may be alerted to transition from a sleep state to an active state based on the present location of the mobile device user. This location may be determined, by way of example and without limitation, via GPS, Wi-Fi, or cell tower signals, as well as by previous geographic position signal values and with the aid of any suitable techniques, …In yet other embodiments, if the user is in or near a social entity (on the social network) of interest to the user (e.g., as determined by the user's profile on the social network), the processors of the mobile device may be alerted to transition to an awake state, and similarly, if the user is not near any (or near a threshold number) of social entities of interest to the user, the processors may transition to a sleep state. For example, if the user is near a location that is also a social entity, and the user frequents this location (determined, for example, by the user's social network check-ins to that location), the processors of the mobile system may be alerted to transition to an active state. …As another example, a history of the user's locations may also be used to create a trajectory, and the trajectory information may similarly be used to alert the processors of the mobile system depending on the locations or contacts of interest near to the user's trajectory. Any combination of the factors described herein may be used to determine whether the processors of the mobile device should be alerted to transition their state. Additionally, the frequency with which any of the processors of the mobile device are alerted to transition to an awake state (e.g., every ten minutes) may be determined dynamically based, for example, on the user's location, as well as by any suitable factor including, for example, those mentioned herein.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Harrison, and Nishiguchi by incorporating “The geographic-positioning component, and dynamic processor duty cycle”, as taught by Papakipos. One could have been motivated to do so in order to determine on a periodic basis a current location of the device and apply a processor to transition from a sleep state to an active state based on the present location of the mobile device user [ Papakipos, Abstract, ¶29].
Regarding claims 53, and 63, Harrison discloses when the private device is a distance less than or equal to the radial displacement from the public device, the connection strength does not decrease by more than a degradation threshold [Abstract, Techniques and tools for controlling public output devices (e.g., public display devices) with client devices over a network. In some examples, a time-limited proximity code is displayed by a public display device, and a client device can provide the code via a public network to verify that the client device is present within a proximity zone and is allowed to control the public display], and [ ¶16, Described techniques and tools can be used to verify a user's presence within a proximity zone and restrict access by distant and/or unauthorized users], and [¶32, In some scenarios, it is desirable to limit access to public output devices to users that are in a local area (e.g., to avoid disruption by intruders at remote locations). As used herein, the term "proximity" is used to describe a measure of closeness (e.g., physical distance) between devices (e.g., the client device 210 and the public output device 220). In the example shown in FIG. 2, the client device 210 is within a proximity zone 290 which also includes the public output device 220. The presence of the client device 210 within the proximity zone 290 indicates that the client device is considered to be close enough to control the public output device 220, and [ ¶34].
Regarding claims 54, and 64, Harrison discloses, wherein the degradation threshold is an amount of the connection strength that represents a significant change in a quality of a connection [ ¶34, tones transmitted by a public display device or a client device can be received by the other device and used to verify audio proximity. The size and shape of an audio proximity zone can vary based on factors such as strength of the audio signal or acoustics of a particular venue. Alternatively, other signals or protocols can be used to verify proximity].
Regarding claims 55, and 65, Harrison, and Papakipos do not explicitly disclose, however, Nishiguchi discloses, wherein, when the private device is a distance less than or equal to the radial displacement from the public device, the anticipated processing ratio does not increase by more than a processing limit threshold [ see FIG. 1 and corresponding text for more details, ¶49, he physical machine and the terminal apparatus 3 may be connected to each other wirelessly or by a cable such as a display cable], and [ ¶50, The computer 3 and the physical machine 1 may be connected to each other by a USB (universal serial bus) cable or a communication network, such as the Internet or a LAN (local area network), and transmit or receive information according to a predetermined protocol. The computer 3 may be connected to the physical machine 1 by the LAN. The user of the computer 3 starts the operation environment 2 (hereinafter, referred to as a VM 2) through the physical machine 1. A plurality of VMs 21, 22, 23, . . . that is logically divided is operated on the physical machine 1], and ¶51, The physical machine 1 allocates, to each VM 2, a first processing amount indicating the amount, of hardware resource (hereinafter, referred to as a hardware resource) of the physical machine 1 allocated to each VM 2. In the example illustrated in FIG. 1, the first processing amount indicates a CPU usage rate, which is one of the hardware resources, allocated from the physical machine 1 to each VM 2. As represented by a circle graph, as can be seen from comparison to the VM 22 and the VM 23, the first processing amount allocated to the VM 21 is more than that allocated to the VM 22 and the VM 23. That is, in the circle graph illustrated in FIG. 1, the first processing amount allocated to each VM is hatched. The VM 2 executes an application program (hereinafter, referred to as an application) on each VM 2. A second processing amount varies depending on the kind of application being executed, the number of applications being executed, or the content of the process of the application being executed], and [¶52], and [ see FIG. 2 and corresponding text for more details, ¶57], and [¶62, The VM management unit 178 monitors the operating states or the stationary states of the VMs 21 to 23, and allocates the hardware resources 10 under predetermined conditions stored in the HD 15. The first processing amount, which is one of the hardware resources 10 allocated, is, for example, a CPU usage rate, an HD usage rate, or a NIC usage rate. The CPU usage rate means the ratio of the time when the VM 2 being operated occupies the CPU 11. For example, when the CPU usage rate is 50%, the corresponding VM 2 occupies the CPU 11 for 0.5 second with respect to 1 second], and [¶¶63-65].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Harrison, and Papakipos by incorporating “information processing apparatus/ physical machine/Server with resource allocation capability”, as taught by Nishiguchi. One could have been motivated to do so in order for the server to incorporate the first processing amount allocated to the VM based on the CPU usage rate and a second processing amount based on what kind of application each VM executes. [ Nishiguchi, ¶51].
Regarding claims 56, and 66, Harrison, and Papakipos do not explicitly disclose, however, Nishiguchi discloses, wherein the processing limit threshold is a maximum change in processing loads before a connection between the private device and the public device becomes unstable [ see FIG. 1 and corresponding text for more details, ¶49, he physical machine and the terminal apparatus 3 may be connected to each other wirelessly or by a cable such as a display cable], and [ ¶50, The computer 3 and the physical machine 1 may be connected to each other by a USB (universal serial bus) cable or a communication network, such as the Internet or a LAN (local area network), and transmit or receive information according to a predetermined protocol. The computer 3 may be connected to the physical machine 1 by the LAN. The user of the computer 3 starts the operation environment 2 (hereinafter, referred to as a VM 2) through the physical machine 1. A plurality of VMs 21, 22, 23, . . . that is logically divided is operated on the physical machine 1], and ¶51, The physical machine 1 allocates, to each VM 2, a first processing amount indicating the amount, of hardware resource (hereinafter, referred to as a hardware resource) of the physical machine 1 allocated to each VM 2. In the example illustrated in FIG. 1, the first processing amount indicates a CPU usage rate, which is one of the hardware resources, allocated from the physical machine 1 to each VM 2. As represented by a circle graph, as can be seen from comparison to the VM 22 and the VM 23, the first processing amount allocated to the VM 21 is more than that allocated to the VM 22 and the VM 23. That is, in the circle graph illustrated in FIG. 1, the first processing amount allocated to each VM is hatched. The VM 2 executes an application program (hereinafter, referred to as an application) on each VM 2. A second processing amount varies depending on the kind of application being executed, the number of applications being executed, or the content of the process of the application being executed], and [¶52], and [ see FIG. 2 and corresponding text for more details, ¶57], and [¶62, The VM management unit 178 monitors the operating states or the stationary states of the VMs 21 to 23, and allocates the hardware resources 10 under predetermined conditions stored in the HD 15. The first processing amount, which is one of the hardware resources 10 allocated, is, for example, a CPU usage rate, an HD usage rate, or a NIC usage rate. The CPU usage rate means the ratio of the time when the VM 2 being operated occupies the CPU 11. For example, when the CPU usage rate is 50%, the corresponding VM 2 occupies the CPU 11 for 0.5 second with respect to 1 second], and [¶¶63-65].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Harrison, and Papakipos by incorporating “information processing apparatus/ physical machine/Server with resource allocation capability”, as taught by Nishiguchi. One could have been motivated to do so in order for the server to incorporate the first processing amount allocated to the VM based on the CPU usage rate and a second processing amount based on what kind of application each VM executes. [ Nishiguchi, ¶51].
Regarding claims 57, and 67, generating an authorization key unique for the private device, wherein the authorization key is required to cause the public device to execute the user commands received from the private device.
Papakipos does not explicitly disclose, however, the combination of Harrison, and Nishiguchi disclose this limitation as:
Harrison discloses: [¶40, In any of the examples described herein, the authorization of a user and/or client device to control a public output device can be determined from the confirmation of a proximity code. Confirmation of a proximity code can involve, for example, comparing (e.g., by a server) a proximity code transmitted by a client device with one or more legitimate codes (e.g., a single legitimate code, a set of legitimate proximity codes in a database). Legitimate codes can be generated and transmitted codes can be confirmed by a public display device or some other device (such as a server). Legitimate codes can be stored, for example, in memory or other storage of a public display device or some other device (such as a server). When the transmitted proximity code is confirmed, the client device can receive authorization data. Authorization data can include, for example, an authorization code or an identifier, such as a session ID, for a communication session with a public display device].
Nishiguchi discloses: [¶57, The physical machine 1 in a stationary state starts up and the user who wants to use the VM 21 uses the computer 3 to start the physical machine 1. The computer 3 outputs a start command to the physical machine 1. In addition, the computer 3 outputs identification information (hereinafter, referred to as a VMID) for specifying one of the pluralities of VMs 2 which the user wants to start and a start command for the VM 2 to the physical machine 1].
Regarding claims 58, and 68, wherein executing, at the public device, the user commands received from the private device further comprises: verifying that the private device is within the predetermined proximity to the public device; and in response to validating the authorization key and verifying that the private device is within the predetermined proximity to the public device, executing, at the public device, the user command.
Papakipos does not explicitly disclose, however, the combination of Harrison, and Nishiguchi disclose this limitation as:
Harrison discloses: [ ¶16, Described techniques and tools can be used to verify a user's presence within a proximity zone and restrict access by distant and/or unauthorized users], and [0032] In some scenarios, it is desirable to limit access to public output devices to users that are in a local area (e.g., to avoid disruption by intruders at remote locations). As used herein, the term "proximity" is used to describe a measure of closeness (e.g., physical distance) between devices (e.g., the client device 210 and the public output device 220). In the example shown in FIG. 2, the client device 210 is within a proximity zone 290 which also includes the public output device 220. The presence of the client device 210 within the proximity zone 290 indicates that the client device is considered to be close enough to control the public output device 220], and [ ¶34... requiring Bluetooth or local network connections to verify proximity can be inconvenient for some users. ...].
Nishiguchi discloses: [¶57, The physical machine 1 in a stationary state starts up and the user who wants to use the VM 21 uses the computer 3 to start the physical machine 1. The computer 3 outputs a start command to the physical machine 1. In addition, the computer 3 outputs identification information (hereinafter, referred to as a VMID) for specifying one of the pluralities of VMs 2 which the user wants to start and a start command for the VM 2 to the physical machine 1].
Regarding claims 59, and 69, Harrison discloses invalidating, at the public device, the authorization key, by determining that the private device is outside the predetermined proximity to the public device; and in response to invalidating the authorization key, ending a session[¶13, Techniques and tools are described for controlling public display devices (or public output devices with other types of controllable output) with client devices (e.g., private computing devices such as mobile devices) over a network (e.g., the Internet). Described techniques and tools use proximity and/or authentication information to manage users that are permitted to control public displays. Security can be enhanced by restricting access by distant and/or anonymous users. In some examples, a proximity code (e.g., a visual proximity code such as a text string or an image such as a bar code) is displayed on the public display, and a user can provide the code (e.g., by typing the code on a keyboard, capturing an image of the code, or by some other method appropriate for the code) to verify that the user is present within a proximity zone and is allowed to control the public display], and [¶16, Described techniques and tools can be used to verify a user's presence within a proximity zone and restrict access by distant and/or unauthorized users.], and [¶40] In any of the examples described herein, the authorization of a user and/or client device to control a public output device can be determined from the confirmation of a proximity code. Confirmation of a proximity code can involve, for example, comparing (e.g., by a server) a proximity code transmitted by a client device with one or more legitimate codes (e.g., a single legitimate code, a set of legitimate proximity codes in a database). Legitimate codes can be generated and transmitted codes can be confirmed by a public display device or some other device (such as a server). Legitimate codes can be stored, for example, in memory or other storage of a public display device or some other device (such as a server). When the transmitted proximity code is confirmed, the client device can receive authorization data. Authorization data can include, for example, an authorization code or an identifier, such as a session ID, for a communication session with a public display device].
Regarding claims 60, and 70, Harrison discloses, further comprising receiving a communication from the private device indicating that a user wishes to use the public device [Abstract, Techniques and tools for controlling public output devices (e.g., public display devices) with client devices over a network. In some examples, a time-limited proximity code is displayed by a public display device, and a client device can provide the code via a public network to verify that the client device is present within a proximity zone and is allowed to control the public display. Once authorized, the client device can provide control data to control visual content on the public display].
Claims 61, and 71 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2013/0143651) issued to Harrison (Filed in IDS 08/17/2023) and in view of US Patent No. (US2010/0251254) issued to Nishiguchi, and further in view of Papakipos (US20170070463), and further in view of US Patent No. (US2022/0058044) issued to ONO, and further in view of US Patent No. (US2020/0142802) issued to Norris.
Regarding claims 61, and 71 , wherein determining the anticipated processing ratio between the private device and the public device further comprises: determining, a first processing limit of the private device based on the device identifier; determining, an average processing requirement associated with at least one application in the application usage history; identifying, power consumption information of the private device based on the device identifier; determining, a first anticipated processing load for the private device based on the power consumption information and the first processing limit; determining, a second anticipated processing load for the public device, wherein a sum of the first anticipated processing load and the second anticipated processing load is greater than or equal to the average processing requirement; and determining, the anticipated processing ratio between the private device and the public device based on the first anticipated processing load and the second anticipated processing load.
Papakipos does not explicitly disclose, however, the combination of Harrison, Nishiguchi, ONO, and Norris discloses:
Harrison discloses: [¶23, The illustrated mobile device 100 can include a controller or processor 110 (e.g., signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing such tasks as signal coding, data processing, input/output processing, power control, and/or other functions. An operating system 112 can control the allocation and usage of the components 102 in various ways, and can provide support for one or more application programs 114. The application programs can include common mobile computing applications (e.g., image-capture applications, email applications, calendars, contact managers, web browsers, messaging applications), or any other computing application], and [ ¶34... requiring Bluetooth or local network connections to verify proximity can be inconvenient for some users. ...].
Nishiguchi discloses: [ see FIG. 1 and corresponding text for more details, ¶49, he physical machine and the terminal apparatus 3 may be connected to each other wirelessly or by a cable such as a display cable], and [ ¶50, The computer 3 and the physical machine 1 may be connected to each other by a USB (universal serial bus) cable or a communication network, such as the Internet or a LAN (local area network), and transmit or receive information according to a predetermined protocol. The computer 3 may be connected to the physical machine 1 by the LAN. The user of the computer 3 starts the operation environment 2 (hereinafter, referred to as a VM 2) through the physical machine 1. A plurality of VMs 21, 22, 23, . . . that is logically divided is operated on the physical machine 1], and ¶51, The physical machine 1 allocates, to each VM 2, a first processing amount indicating the amount, of hardware resource (hereinafter, referred to as a hardware resource) of the physical machine 1 allocated to each VM 2. In the example illustrated in FIG. 1, the first processing amount indicates a CPU usage rate, which is one of the hardware resources, allocated from the physical machine 1 to each VM 2. As represented by a circle graph, as can be seen from comparison to the VM 22 and the VM 23, the first processing amount allocated to the VM 21 is more than that allocated to the VM 22 and the VM 23. That is, in the circle graph illustrated in FIG. 1, the first processing amount allocated to each VM is hatched. The VM 2 executes an application program (hereinafter, referred to as an application) on each VM 2. A second processing amount varies depending on the kind of application being executed, the number of applications being executed, or the content of the process of the application being executed], and [¶52], and [ see FIG. 2 and corresponding text for more details, ¶57], and [¶62, The VM management unit 178 monitors the operating states or the stationary states of the VMs 21 to 23, and allocates the hardware resources 10 under predetermined conditions stored in the HD 15. The first processing amount, which is one of the hardware resources 10 allocated, is, for example, a CPU usage rate, an HD usage rate, or a NIC usage rate. The CPU usage rate means the ratio of the time when the VM 2 being operated occupies the CPU 11. For example, when the CPU usage rate is 50%, the corresponding VM 2 occupies the CPU 11 for 0.5 second with respect to 1 second], and [¶¶63-65].
ONO discloses: [¶112, An ID of a managed node is described in 0901. A physical CPU usage rate of a managed node is described in 0902. The physical CPU usage rate is a ratio of a processing amount consumed by all desktop VMs on a managed node relative to a processing amount that can be handled by all CPU cores available on the managed node], and [¶116, An ID of the desktop VM is described in 1001. A virtual CPU usage rate of a desktop VM is described in 1002. The virtual CPU usage rate is a ratio of a processing amount consumed by all applications on a desktop VM relative to a processing amount that can be handled by all CPU cores assigned to the desktop VM].
Norris discloses: [¶18, The resource utilization of computers and networked computing infrastructure may be improved by monitoring the infrastructure of an application by collecting application runtime data regarding individual software components that are invoked in the application. In an event-driven programming construct involving an event loop, a loop iteration utilization metric or an event loop load metric may be determined that indicates an approximation of proportional use of available resources. The loop iteration utilization metric and the event loop load metric may be used to trigger auto-scaling events to scale application cluster resources both up and down to meet demand with improved fidelity compared with known metrics such as central processing unit (CPU) usage. The loop iteration utilization or the event loop load metrics may also be used to inform load balancing mechanisms to distribute work across a cluster of processes according to their ability to handle additional work. When used in conjunction with CPU usage, the loop iteration utilization metric and the event loop load metric may indicate whether an application has reached its resource limit due to application code limitations or due to amount of resources allocated to the process].
Therefore, at the time of invention was made, it would have been obvious to one ordinary skill in the art by combining Harrison, Nishiguchi, ONO, and Norris teaching in order for determining the anticipated processing ratio between the private device and the public device
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Schink (US2014/0250447) [0078] In some embodiments, display 312 may display the visual indication to user 502 intermittently. The frequency at which the visual indication is intermittently displayed may be a function of the relative location of user 510 to viewing area 506 or the speed of user 510. For example, control circuitry 304 may compute a likelihood value based on the distance that user 510 is from viewing area 506. Control circuitry 304 may then compute a frequency value that scales with the inverse of the likelihood value. If user 510 is 5 meters away from viewing area 506, display 312 may display the visual indication 1 time per second. If user 510 is 2 meters away from viewing area 506, display 312 may display the visual indication 4 times per second. In some embodiments, the frequency of the intermittent indication may be a function of the speed at which user 510 is approaching viewing area 506. In some embodiments, the frequency of the intermittent visual indication may vary continuously with respect to the movements of user 510], and [0084] If control circuitry 304 determines that user 510 is approaching viewing area 506 or is within a certain distance of user equipment device 300, the volume of any audio associated with the media content can be regulated control circuitry 304. User 502 may wish to enable this feature in order to prevent user 510 from hearing any audio content associated with the private content. In some embodiments, user 502 may calibrate private viewing system 400 in order to determine an acceptable volume level such that the volume will be effectively inaudible when user 502 is located at a particular distance from user equipment device 300. In some embodiments, the calibration may be determined automatically by using any suitable audio detection devices connected to communications network 414. Once private viewing system 400 is properly calibrated, it may control circuitry 304 can determine that user 510 is a particular distance away from user equipment device 300, the volume of the content will be decreased accordingly. As the distance between user 510 and user equipment device 300 decreases, the volume will be reduced. In some embodiments, the volume level may be varied with the inverse square of distance from user 510 to user equipment device 300. In some embodiments, user 502 may receive a visual indication that the volume of the media content is being reduced. This indication may be displayed in addition to the warning indication 522. In some embodiments, the volume will be reduced without any change to the visual display of the content.
Balle (US2018/0026910) [ [0048] Additionally, in the illustrative embodiment, the orchestrator server 1240 is configured to organize the telemetry data into a hierarchical model that is indicative of a relationship between the managed nodes (e.g., a spatial relationship such as the physical locations of the managed nodes within the data center 1100 and/or a functional relationship, such as groupings of the managed nodes by the customers the nodes provide services for, the types of functions typically performed by the managed nodes, managed nodes that typically share or exchange workloads among each other, etc.). Based on differences in the physical locations and hardware in the managed nodes, a given workload may exhibit different resource utilizations (e.g., cause a different internal temperature, use a different percentage of processor or memory capacity) across different managed nodes 1260. The orchestrator server 1240, in the illustrative embodiment, is configured to determine the differences based on the telemetry data stored in the hierarchical model and factor the differences into a prediction of future resource utilization of a workload if the workload is reassigned from one managed node to another managed node. By taking into account these differences, the orchestrator server 1240 may more accurately balance resource utilization among the workloads and increase the achievement of one or more of the resource allocation objectives without decreasing the achievement of any of the other resource allocation objectives. In the illustrative embodiment, the achievement of a resource allocation objective may be measured, equal to, or otherwise defined as the degree to which a measured value from one or more managed nodes 1260 satisfies a target value associated with the resource allocation objective. For example, in the illustrative embodiment, increasing the achievement may be performed by decreasing the error (e.g., difference) between the measured value (e.g., an operating temperature of a managed node 1260) and the target value (e.g., a target operating temperature). Conversely, decreasing the achievement may be performed by increasing the error (e.g., difference) between the measured value and the target value.
Raith (US6493550) teaches Proximity systems in conjunction with radiocommunication systems are described. Mobile stations include proximity detectors which recognize proximity signals transmitted by a proximity system. This recognition triggers a search, for example, for a private radiocommunication control channel. In this way, mobile stations have a mechanism which is independent of public radiocommunication cell characteristics for recognizing the presence of a private radiocommunication system].
Kuper et al. (US2016/0149891) teaches Examples provided herein are directed to a computing device and media playback system sharing access to a media service corresponding to a media application installed on the computing device. In one example, a media playback system may be configured to (i) receive from the computing device an authorization code that corresponds to a media application installed on the computing device that is authorized to access media from a media service, (ii) transmit to the media service an authorization request with the authorization code, (iii) receive from the media service an authorization token that facilitates obtaining media from the media service, and (iv) transmit to the media service a request for media for playback by the media playback system, where the request for media includes the authorization token.
Belk et al. (US2014/0364056) teaches techniques for automatically configuring and controlling a digital media device are described. A digital media device can be configured or controlled by a mobile device, e.g., a smart mobile phone. When the digital media device is being configured, the digital media device can broadcast a signal, indicating that the digital media device is requesting configuration information from a mobile device. A mobile device located in proximity of the digital media device, upon detecting the signal, can perform various security checks to determine that the request is legitimate, and then open a communication channel with the digital media device. The mobile device can provide user preferences of the mobile device, as well as credentials for accessing and downloading remote content, to the digital media device through the communication channel. Upon receiving the configuration information, the digital media device can use parameters in the configuration information as its settings.
Murphy (US2014/0280543) teaches the present disclosure provides systems and methods for a social networking service that can connect users in a similar industry or business based on the location of a user's electronic devices. The method can include receiving profile and location information from a first electronic device, determining based on an association method relevant and proximally located electronic devices, and transmitting the determined proximal electronic devices to first electronic device.
Rowe (US28, 026, 805) teaches methods, systems, and apparatus, including computer program products, for tracking media history using a mobile device. In some implementations, a method includes receiving a notification indicating that a mobile device is in communication range of a first player device. First media context information specifying media content being played by the first device and capabilities for the first device is received. The capabilities indicate types of media content that can be played by the first device. The first media context information is associated with the first player device. A second notification indicating that the mobile device is in communication range of a second player device is received. Second media context information is received. The second context information is associated with the second device. A history of media content is generated from the first media context information and the second media context information.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496