DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-20 are presented for examination.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 5-6 and 17-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As to claim 5, the policy may include “at least one of a list of authorized mobile devices or a list of unauthorized mobile devices,” but then requires automatic transmission based on the second mobile device being on the list of authorized mobile devices. Thus, in the specific scenario wherein if the policy includes only an unauthorized device list, the operative condition is unclear.
As to claim 6, the policy may include “at least one of a list of authorized applications or a list of unauthorized applications,” but then requires automatic transmission based on the second application being on the list of authorized applications. Thus, in the specific scenario wherein if the policy includes only an unauthorized application list, the operative condition is unclear.
As to claims 17, it is rejected for the same reasons as stated in the rejection of claim 5.
As to claims 18, it is rejected for the same reasons as stated in the rejection of claim 6.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kieft et al. (hereinafter KIEFT) (US 2013/0194374 A1) in view of Tyagi et al. (hereinafter TYAGI) (US 2017/0310661 A1).
As to claim 1, KIEFT teaches a first mobile device, comprising:
at least one memory (Storage 110) (Fig. 1); and
at least one processor (Processor 135) coupled with the at least one memory configured to cause the first mobile device (First Electronic Device 200) (Figs. 1 and 2) to:
detect an event (establishment/initiation of telephone/video communication and/or a request to engage in sharing an application, which may take place during a telephone or FACETIME/video communication, etc.) associated with a first application (Application Sharing Module 135 or a phone/video communication application) on the first mobile device (First Electronic Device 200) ([0011]-[0012]; [0036]-[0038]; Fig. 2);
transmit an interface (screen image 220 may be transmitted with an instruction regarding how the image is to be displayed or the screen image itself may be considered an instruction regarding display insofar as the remote device may interpret receipt of the screen image as an instruction to automatically display the image) of a second application (shared application selected for sharing during the communication session) installed on the first mobile device (first electronic device 200) to a second mobile device (remote electronic device 205) based on the event associated with the first application and a request (request to share the application) to use the second application (request to share the application and if the user of the second device accepts the request to share, the application may be initiated on the second device) ([0009]; [0035]; [0038]; [0048]-[0049]; Figs 1-3).
KIEFT does not explicitly teach to receive an authorization code from a remote device associated with the second application; and transmit the authorization code to the second mobile device.
However, TYAGI teaches to receive an authorization code (Authorization Data 338 includes an alphanumeric phrase 322 (e.g., LZX24YQ)) from a remote device (Provider 330) associated with the second application (Provider having a provider service 332 and/or service portal 334) ([0033]; Fig. 3); and
transmit the authorization code (Authorization Data 338) to the second mobile device (VU 117 may automatically receive authorization data at a first device from a provider via a messaging service and in response to determining that a connection between the first device and a second device is a validated connection, automatically transmit the authorization data to the second device, via the validated connection) (Abstract; [0021]; [0033]).
It would have been obvious to one of ordinary skill in the art before the effective date of the application to modify KIEFT’s application sharing system/method between devices to receive an authorization code from a remote device associated with the second application, and transmit the authorization code to the second mobile device, as taught in TYAGI. The suggestion/motivation for doing so would have been to provide the predicted result of improving user convenience through automation of a login process using authentication data between multiple devices, rather than having to manually enter the code, which can introduce the possibility of user error from misreading the authorization code and/or from mistyping the authorization code. Additionally, if the client/user is not near the second device, the client is unable to access the authorization code and thus is unable to complete the login to the service portal (TYAGI – [0002]). Therefore, one of ordinary skill in the art would have been motivated to combine the teachings of KIEFT and TYAGI to obtain the broadest reasonable interpretation of claim 1.
As to claim 2, KIEFT teaches the first mobile device of claim 1, wherein the first application and the second application execute concurrently (simultaneously and application data may be overlaid on the image) on the first mobile device ([0011]; [0022]).
As to claim 3, KIEFT (acknowledgement and confirmation of sharing) ([0047]) in view of TYAGI (accept authorization data 338 and/or approve transmission) ([0044]) teaches the first mobile device of claim 1, wherein the at least one processor is configured to display, in response to receiving the authorization code, a prompt to approve transmitting the authorization code to the second mobile device, wherein the first mobile device transmits the authorization code based on the first mobile device detecting an approval to transmit the authorization code in response to display of the prompt.
As to claim 4, KIEFT (certain applications may be shared and certain applications may be prevented from sharing, sharing characteristics or permissions, privacy settings, etc.) ([0039]) in view of TYAGI (automatic sending/receiving of authorization data 338 via validated connection 340) ([0043]; Fig. 3) teaches the first mobile device of claim 1, wherein the first mobile device transmits at least one of the interface of the second application or the authorization code automatically based on a preconfigured policy.
As to claim 5, KIEFT (user interface may permit a user to designate a certain list of people, devices and/or contacts for each application, or a group of applications, and enable certain sharing characteristics or permissions for that group only. For example, particular contacts may be specified for different privacy settings (or privacy designators, as discussed below) and identified through the user interface by name, telephone number, device identifier and the like) ([0039]) in view of TYAGI (trusted devices identified in the at least one client profile and/or device profile; trusted friend or coworker, etc.) ([0032]; Fig. 3) teaches the first mobile device of claim 4, wherein: the preconfigured policy comprises at least one of a list of authorized mobile devices or a list of unauthorized mobile devices, and transmitting at least one of the interface of the second application or the authorization code automatically is based on the second mobile device being on the list of authorized mobile devices.
As to claim 6, KIEFT teaches the first mobile device of claim 4, wherein: the preconfigured policy comprises at least one of a list of authorized applications or a list of unauthorized applications, and transmitting at least one of the interface of the second application or the authorization code automatically is based on the second application being on the list of authorized applications (certain applications may be restricted from sharing data. For example, a device administrator and/or manufacturer may prevent certain applications from being shared; user interface may permit a user to designate a certain list of a group of applications, and enable certain sharing characteristics or permissions for that group only) ([0036]; [0039]; Figs 1-3).
As to claim 7, KIEFT (Abstract; [0012]) in view of TYAGI (VU 117 may automatically receive authorization data at a first device from a provider via a messaging service and in response to determining that a connection between the first device and a second device is a validated connection, automatically transmit the authorization data to the second device, via the validated connection; VU 117 may be a browser plugin module that integrates within an internet browser of application(s) 118) (Abstract; [0021]) teaches the first mobile device of claim 1, wherein the at least one processor is configured to cause the first mobile device to: receive the authorization code via the second application on the first mobile device; and transmit the authorization code to the second mobile device via the second application.
As to claim 8, KIEFT (transmitting the instruction or interface to the second electronic device) ([0012]; Fig. 4) in view of TYAGI (authorization data 338 is contained within a message such as a short message service (SMS) message) ([0033]; Figs 1-3) teaches the first mobile device of claim 1, wherein the at least one processor is configured to cause the first mobile device to: receive the authorization code via a text messaging application of the first mobile device; and transmit the authorization code to the second mobile device via the second application based on the second application acquiring the authorization code from the text messaging application.
As to claim 9, KIEFT teaches the first mobile device of claim 1, wherein: the event includes an active use of the first application on the first mobile device at a time of the request (sharing when another communication is already according, e.g, an audio or video communication, such as a phone call or FACETIME video conference); or the event includes a scheduled use of the first application on the first mobile device that conflicts with using the second application on the first mobile device ([0036]-[0037]).
As to claim 10, KIEFT teaches the first mobile device of claim 1, wherein the request to use the second application includes at least one of a notification (first electronic device receives confirmation of sharing from the second electronic device) on a display of the first mobile device or a message received at the first mobile device (first electronic device 200 receives an acknowledgement) ([0012]; [0047]).
As to claim 11, KIEFT teaches the first mobile device of claim 1, wherein the interface of the second application is transmitted in response to an approval of the request received at the first mobile device (user interface may permit a user to designate a certain list of people, devices and/or contacts for each application, or a group of applications, and enable certain sharing characteristics or permissions for that group only. For example, particular contacts may be specified for different privacy settings (or privacy designators, as discussed below) and identified through the user interface by name, telephone number, device identifier and the like) ([0039]; [0047]).
As to claim 12, KIEFT teaches the first mobile device of claim 1, wherein the at least one processor is configured to cause the first mobile device to terminate transmission of the interface of the second application to the second mobile device based on monitoring information of the second application indicating that the second application is closed on the second mobile device or based on user input received at the first mobile device ([0055]; [0068]-[0069]; [0078]).
As to claim 13, KIEFT teaches the first mobile device of claim 1, wherein the interface of the second application transmitted to the second mobile device differs (two unique views or two different screen views generated from remote and local inputs) from an interface displayed on the first mobile device that is associated with the second application ([0044]-[0045]).
As to claim 14, TYAGI teaches the first mobile device of claim 1, wherein: the first application utilizes a first wireless technology; and the second application utilizes a second wireless technology different from the first wireless technology (Data Processing System 100, Mobile Device 200, and Applications 118 utilizing Wi-Fi network, cellular network, Bluetooth network, WANET, etc.) ([0028]; [0034]; Figs 1-2).
As to claim 15, it is rejected for the same reasons as stated in the rejection of claim 1.
As to claim 16, it is rejected for the same reasons as stated in the rejection of claim 4.
As to claim 17, it is rejected for the same reasons as stated in the rejection of claim 5.
As to claim 18, it is rejected for the same reasons as stated in the rejection of claim 6.
As to claim 19, it is rejected for the same reasons as stated in the rejection of claim 12.
As to claim 20, it is rejected for the same reasons as stated in the rejection of claim 1.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH TANG whose telephone number is (571)272-3772. The examiner can normally be reached Monday-Friday 7AM-3PM.
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, Bradley Teets can be reached at 571-272-3338. 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.
/KENNETH TANG/Primary Examiner, Art Unit 2197
Prosecution Insights