DETAILED ACTION
Status of Claims:
Claims 1 – 23 are pending. This rejection is FINAL.
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 .
Response to Arguments
Applicant's arguments in the amendments, filed 10/29/2025, have been fully considered but they are not persuasive. The reasons set forth below.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 10, 12, 14, and 21 – 23 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Mahdi (US 8838694).
As per claim 1, a method, comprising:
providing, by a first device directly to a second device, an invitation to a collaborative session associated with the first device (FIG. 4a illustrates a message exchange in establishing a collaborative session between a USER A and a USER B … The message exchange may begin with USER A 405 initiating the collaborative session, See Col. 10, Lines 32 - 57);
receiving, by the first device from the second device in response to the invitation, a request to join the collaborative session (Second SCC AS 412, upon receipt of the join session message from USER B 407, may send a join session message of its own to first SCC AS 410 (shown as event #5). The join session message may be in the form of a JOIN SESSION message or equivalent message, See Col. 11, Lines 6 - 15);
providing, from the first device to the second device over a network, an authorization for the second device to control the collaborative session (First SCC AS 410 may check a profile of USER A 405 for authorization as well as to determine if USER B 407 has sufficient privilege to share media and control (block 420), See Col. 10, Lines 42 - 57); and
modifying, by the first device, an output of the first device based on a control command from the second device (Second SCC AS 412 may check a profile of USER B 407 for authorization as well as to determine if USER A 405 has sufficient privilege to share media and control (block 422). According to an embodiment, USER A 405 may have sufficient privilege to share media and control if USER A 405 has full collaboration privilege), See Col. 10, Lines 58 - 65).
As per claim 10, the method of claim 1, wherein the collaborative session comprises outputting media content, by the first device, via a third device that is separate from the first device, and wherein the control command from the second device comprises a selection of the media content (First IMS user 205 (first device) may configure first collaborative session 200 so that video from video server 218 may be displayed on display 214 (third device) through IMS 220 and a voice connection may be established between telephone 212 and UE 216 through PSTN 213, See Col. 8, Lines 34 - 52).
As per claim 12, the method of claim 1, wherein the collaborative session comprises a data sharing session (Users 110 through 112 may participate in sharing of control, data, and media in collaborative session 100, while user 115 may participate in sharing of data and media and may assume control of collaborative session 100, See Col. 8, Lines 7 - 12).
As per claim 14, a method, comprising:
receiving, by a first device directly from a second device, an invitation to a collaborative session associated with the second device (FIG. 4a illustrates a message exchange in establishing a collaborative session between a USER A and a USER B … The message exchange may begin with USER A 405 initiating the collaborative session, See Col. 10, Lines 32 - 57);
providing, by the first device to the second device in response to the invitation, a request to join the collaborative session (Second SCC AS 412, upon receipt of the join session message from USER B 407, may send a join session message of its own to first SCC AS 410 (shown as event #5). The join session message may be in the form of a JOIN SESSION message or equivalent message, See Col. 11, Lines 6 - 15);
receiving, at the first device from the second device over a network, an authorization for the first device to control the collaborative session (First SCC AS 410 may check a profile of USER A 405 for authorization as well as to determine if USER B 407 has sufficient privilege to share media and control (block 420), See Col. 10, Lines 42 - 57); and
providing, by the first device, a control command for controlling an output of the second device via the collaborative session (Second SCC AS 412 may check a profile of USER B 407 for authorization as well as to determine if USER A 405 has sufficient privilege to share media and control (block 422). According to an embodiment, USER A 405 may have sufficient privilege to share media and control if USER A 405 has full collaboration privilege), See Col. 10, Lines 58 - 65).
As per claim 21, the method of claim 14, wherein the collaborative session comprises at least one of: a media output session, a document editing session, a data sharing session, a mapping session, or a group communications session (Users 110 through 112 may participate in sharing of control, data, and media in collaborative session 100, while user 115 may participate in sharing of data and media and may assume control of collaborative session 100, See Col. 8, Lines 7 - 12).
As per claim 22, a device, comprising:
a memory; and
one or more processors configured to:
provide, directly to a second device, an invitation to a collaborative session associated with the device (FIG. 4a illustrates a message exchange in establishing a collaborative session between a USER A and a USER B … The message exchange may begin with USER A 405 initiating the collaborative session, See Col. 10, Lines 32 - 57);
receive, from the second device in response to the invitation, a request to join the collaborative session (Second SCC AS 412, upon receipt of the join session message from USER B 407, may send a join session message of its own to first SCC AS 410 (shown as event #5). The join session message may be in the form of a JOIN SESSION message or equivalent message, See Col. 11, Lines 6 - 15);
provide, to the second device over a network, an authorization for the second device to control the collaborative session (First SCC AS 410 may check a profile of USER A 405 for authorization as well as to determine if USER B 407 has sufficient privilege to share media and control (block 420), See Col. 10, Lines 42 - 57); and
modify an output of the device based on a control command from the second device (Second SCC AS 412 may check a profile of USER B 407 for authorization as well as to determine if USER A 405 has sufficient privilege to share media and control (block 422). According to an embodiment, USER A 405 may have sufficient privilege to share media and control if USER A 405 has full collaboration privilege), See Col. 10, Lines 58 - 65).
As per claim 23, the device of claim 22, wherein the collaborative session comprises output of media content, by the device, via a third device that is separate from the device, and wherein the control command from the second device comprises a selection of the media content (First IMS user 205 (first device) may configure first collaborative session 200 so that video from video server 218 may be displayed on display 214 (third device) through IMS 220 and a voice connection may be established between telephone 212 and UE 216 through PSTN 213, See Col. 8, Lines 34 - 52).
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.
The factual inquiries 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.
Claim(s) 2 – 5, 11, 13, and 15 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mahdi (US 8838694) and in view of Leavy (US 10778432).
As per claim 2, Mahdi discloses all limitations of claim 1.
Mahdi however does not expressly disclose:
wherein the invitation is an encrypted invitation, and wherein the method further comprises, prior to providing the invitation, encrypting at least a portion of the invitation using a key previously configured by the first device and the second device.
Leavy discloses:
the method of claim 1, wherein the invitation is an encrypted invitation, and wherein the method further comprises, prior to providing the invitation, encrypting at least a portion of the invitation using a key previously configured by the first device and the second device (The call initiator's secure collaboration application generates a first encryption key. As noted above, the first encryption key may be a 256-bit key derived from a set of pseudorandom bytes. After generating the first encryption key, the call initiator's secure collaboration application encrypts the meeting identifier and the first token using the first encryption key … the encrypted meeting identifier and first token are encapsulated in a secure communication session invitation and transmitted to one or more receivers via a control channel. The invitation is a control message that includes information to configure the secure communication session., See Col. 14, Line 33 – Col. 15, Line 7).
It would have been obvious to an artisan of ordinary skill in the art before the Applicant's effective filing date of the claimed invention to combine Leavy’s teaching of encrypting at least a portion of the invitation using a key, along with providing an invitation to a collaborative session to improve Mahdi’s system. Both Mahdi and Leavy discloses systems for conducting a group collaboration session. Leavy’s system includes generating an encryption key and encapsulating a secure communication session invitation. The combination is an improvement upon the existing system because an invitation to a collaborative session can be provided, as taught by Mahdi, where at least a portion of the invitation can be encrypted by a key, as taught by Leavy, to allow transmission of the secure collaborative communications between devices.
As per claim 3, the method of claim 2, further comprising, by the first device, configuring the key responsive to identifying a contact stored, for the second device, at the first device (Leavy, Database 234 may index information related to the secure collaboration application, such as key information (e.g. a user signing key, an application signing key, etc.), user information (e.g., username, application identifier, etc.), friend information, and communications, See Col. 9, Line 39 – Col. 10, Line 22).
As per claim 4, the method of claim 2, further comprising, by the first device, configuring the key responsive to identifying a previous communication between the first device and the second device (Leavy, Communications transmitted and received by the secure collaboration application, including a message identifier, a hash of the sender's username, a hash of the sender's application identifier, a hash of the receiver's username, a hash of the receiver's application identifier, the communication encryption key, and a timestamp of each communication (previous communication) may be stored in database, See Col. 9, Line 39 – Col. 10, Line 22).
As per claim 5, the method of claim 2, wherein the encrypted invitation comprises a hash of connection information for the collaborative session and the key device (Leavy, Communications transmitted and received by the secure collaboration application, including a message identifier, a hash of the sender's username, a hash of the sender's application identifier, a hash of the receiver's username, a hash of the receiver's application identifier, the communication encryption key, and a timestamp of each communication may be stored in database, See Col. 9, Line 39 – Col. 10, Line 22).
As per claim 11, the method of claim 1, wherein the collaborative session comprises a document editing session (Leavy, Secure communication platform 120 may be configured to facilitate the exchange of messages and communications for users of a secure collaboration application. As used herein, “messages” include … documents, audiovisual files, … and the like. Further, “communications” may include … application data transmitted as part of application sharing or screen sharing function, See Col. 6, Line 63 – Col. 7, Line 18).
As per claim 13, the method of claim 1, wherein the collaborative session comprises a group communications session (Leavy, Encrypted communications may include direct communications (e.g., one-to-one communications between a sender and receiver), group chats, or secure chat room communications, See Col. 9, Line 39 – Col. 10, Line 22).
As per claim 15, the method of claim 14, further comprising: identifying, by the first device and based on the invitation, a contact stored at the first device for the second device (Leavy, User directory may include a corporate directory that include employees' first and last names, usernames, email address, phone numbers, department information, etc. Alternatively, user directory 106 may be a database or table to maintain user information for users of secure communication platform 120, See Col. 6, Lines 30 - 47).
As per claim 16, the method of claim 15, wherein the invitation comprises a value and the value hashed with a key, and wherein identifying the contact comprises:
generating a plurality of local hash values at the first device by hashing the value with each of a plurality of respective keys stored at the first device in connection with a plurality of respective contacts, including the contact, stored at the first device (Leavy, Communications transmitted and received by the secure collaboration application, including a message identifier, a hash of the sender's username, a hash of the sender's application identifier, a hash of the receiver's username, a hash of the receiver's application identifier, the communication encryption key, and a timestamp of each communication may be stored in database 234, See Col. 9, Line 39 – Col. 10, Line 22); and
identifying the contact by identifying one of the local hash values that matches the value hashed with the key from the invitation (Leavy, User directory 106 may serve as a secure directory that includes a table of hashed usernames, a table of application identifiers, and a table of device identifiers for secure collaboration application. Accordingly, user directory 106 may be used to share information about users, systems, networks, services and applications, See Col. 6, Lines 30 - 47).
As per claim 17, the method of claim 16, wherein providing the request to join the collaborative session comprises:
obtaining an identifier of the contact stored at the first device (Leavy, If this is the first time the sending device and the receiving device have communicated, the first device may obtain information about the second device from the secure communication platform, such as the application identifier, the username, and user profile information of the sending device. The first device may store this information in database 234 for subsequent communication exchanges, See Col. 13, Lines 20 - 39); and
providing the request to join the collaborative session to a server along with the obtained identifier (Leavy, A secure collaboration application initializes a secure communication session by generating a meeting identifier and a first token. The secure collaboration application may initialize the secure communication session in response to receiving an input from a user. For example, a user in a one-to-one communication or a group chat may select an icon, such as a telephone icon or a video camera icon, to initiate the secure communication session, See Col. 14, Lines 11 - 32).
As per claim 18, the method of claim 14, wherein providing the control command for controlling the output of the second device comprises providing, from the first device to the second device, a selection of media content for output by the second device (Leavy, Application 224 may be a secure collaboration application that provides users with the ability to participate in voice and video calls, share encrypted content, exchange encrypted communications, and share application data, See Col. 9, Line 39 – Col. 10, Line 22).
As per claim 19, the method of claim 14, wherein providing the control command to the second device over the network comprises providing the request to a server for the collaborative session, for forwarding to the second device by the server (Leavy, In the context of streaming data—such as during voice or video calls and application sharing, management module 232 may be configured to register streams of data with the server, See Col. 9, Line 39 – Col. 10, Line 22).
As per claim 20, the method of claim 14, wherein providing the request to the second device comprises providing the request directly to the second device from the first device (Leavy, Encrypted communications may include direct communications (e.g., one-to-one communications between a sender and receiver), group chats, or secure chat room communications, See Col. 9, Line 39 – Col. 10, Line 22).
Claim(s) 6 – 9 are rejected under 35 U.S.C. 103 as being unpatentable over Mahdi (US 8838694) and in view of Yen (US 11651407).
As per claim 6, Mahdi discloses all limitations of claim 1.
Mahdi however does not expressly disclose:
wherein providing the invitation comprises broadcasting an unencrypted invitation responsive to a user request to invite all nearby devices to the collaborative session.
Yen discloses:
the method of claim 1, wherein providing the invitation comprises broadcasting an unencrypted invitation responsive to a user request to invite all nearby devices to the collaborative session (The ARS may identify that the traveler's mobile device is proximal to the ARS. For instance, the traveler may be standing stationary at a distance of ten feet from the ARS. The ARS may send a request including at least one of a push notification (invitation), a short message service (SMS) message, a multimedia messaging service (MMS) message, a text-message, or electronic mail (E-mail) message to connect to the mobile device. In some instances, the ARS may periodically broadcast a beacon indicating a presence of the ARS, See Col. 5, Lines 28 - 57).
It would have been obvious to an artisan of ordinary skill in the art before the Applicant's effective filing date of the claimed invention to combine Yen teaching of broadcasting an unencrypted invitation to invite all nearby devices to the collaborative session, along with providing an invitation to a collaborative session to improve Mahdi’s system. Both Mahdi and Yen disclose systems for providing invitations to users. Yen’s system includes sending notifications to users in proximity of the device. The combination is an improvement upon the existing system because an invitation to a collaborative session can be provided, as taught by Mahdi, where the invitation can be unencrypted for broadcasting the invite to all nearby devices to the collaborative session, as taught by Yen, to allow transmission of the secure collaborative communications between devices.
As per claim 7, the method of claim 1, wherein providing the invitation comprises providing the invitation based on a determination, by the first device that the second device has been within a proximal range of the first device for at least a predetermined period of time (Yen, The ARS may identify a mobile device using a proximity component that identifies electronic device below a physical distance threshold of the ARS (e.g., within 15 feet of the ARS) and/or above a time threshold. (e.g., a mobile device that is proximal to the ARS for at least ten seconds), See Col. 5, Lines 28 - 57).
As per claim 8, the method of claim 7, further comprising, prior to providing the invitation, determining, by the first device that the second device has been within the proximal range of the first device for at least the predetermined period of time by:
broadcasting, by the first device responsive to a user request to invite all proximal devices to the collaborative session, a first advertisement that does not include information for requesting to join the collaborative session (Yen, In some instances, the ARS may send a request to connect via a mobile application associated with a cellular service provider. In some instances, the request may include an invitation and/or hyperlink to download the mobile application associated with a cellular service provider, See Col. 5, Lines 28 - 57); and
determining, based on a signal strength associated with the first advertisement, that the second device has been within the proximal range of the first device for at least the predetermined period of time (Yen, In some instances, a cellular signal strength threshold may be used to determine a proximity of the UE to the ARS. In various embodiments, the ARS will not authorize and/or send a connection request from or to electronic devices that do not satisfy the distance and/or time thresholds, See Col. 5, Lines 28 - 57).
As per claim 9, the method of claim 8, wherein the invitation comprises a second advertisement that includes the information for requesting to join the collaborative session (Yen, In some instances, the ARS may send a request to connect via a mobile application associated with a cellular service provider. In some instances, the request may include an invitation and/or hyperlink to download the mobile application associated with a cellular service provider, See Col. 5, Lines 28 - 57).
Remarks
Applicant s arguments, with regards to independent claims 1, 14, and 22 and dependent claims 2, 3, and 4, filed on 10/29/2025, have been fully considered but they are not persuasive. The current arguments are based on to independent claims 1, 14, and 22 and dependent claims 2, 3, and 4 which are present in the remarks by the applicant.
With respect to independent claims 1, 14, and 22:
Applicant argues that Mahdi does not disclose “providing, by a first device directly to a second device, an invitation to a collaborative session associated with the first device.” Examiner responds that Mahdi discloses the claimed limitation by teaching that a message exchange between user A and user B begins with an initiation of a collaboration session between two devices, UE-1 which is the first device and UE-2 which is the second device (Col. 10, Lines 32 - 57). While the initiation passes through the SCC AS, it is still a direct initiation between user devices since the servers work in the background only to determine authorization. Hence, Mahdi discloses the claimed limitation as required.
Applicant argues that Mahdi does not disclose “receiving, by the first device from the second device in response to the invitation, a request to join the collaborative session.” Examiner responds that Mahdi discloses the claimed limitation by teaching that the first SCC AS, which is a part of the first device, receives a join session message from the second SCC AS, which is a part of the second device (Col. 11, Lines 6 - 15). The first and second user devices include the SCC AS servers as part of the session setup process however the collaboration itself is only setup for the user devices. For example, according to fig. 4b, user A and user B include the devices that initiate and participate in the session while according to figs. 4c – 4e, provide the background operations for the processing the collaboration session (Col. 11, Lines 16 - 33). Therefore, Mahdi discloses the claimed limitation as required.
Applicant argues that Mahdi does not disclose “providing, from the first device to the second device over a network, an authorization for the second device to control the collaborative session.” Examiner responds that Mahdi discloses the claimed limitation by teaching that the first SCC AS which is associated with the first user device determines if user B of the second device has sufficient privilege to control and share media. According to fig. 4a, the first SCC AS associated with the first device (UE-1) verifies the authorization, the determination of the privilege, for the second device (UE-2) via the second SCC AS. Once it is determined that the second device is authorized, it is granted permission to share and control media (Col. 10, Line 42 – Col. 11, Line 5). Therefore, Mahdi discloses the claimed limitation as required.
With respect to dependent claim 2, Applicant argues that Leavy does not disclose “wherein the invitation is an encrypted invitation, and wherein the method further comprises, prior to providing the invitation, encrypting at least a portion of the invitation using a key previously configured by the first device and the second device.” Examiner responds that Leavy discloses the claimed limitation by teaching that an encryption key is generated to encrypt a meeting identifier, prior to sending out the invitation, which is then encapsulated in the invitation and transmitted (Col. 14, Line 33 – Col. 15, Line 7). Both Mahdi and Leavy discloses systems for conducting a group collaboration session which is an improvement upon the existing system because an invitation to a collaborative session can be provided, as taught by Mahdi, where at least a portion of the invitation can be encrypted by a key, as taught by Leavy, to allow transmission of the secure collaborative communications between devices.
With respect to dependent claim 3, Applicant argues that Leavy does not disclose “comprising, by the first device, configuring the key responsive to identifying a contact stored, for the second device, at the first device.” Examiner responds that Leavy discloses the claimed limitation by teaching that a database indexes information regarding key information and its associations such at user or contact information (Col. 9, Line 39 – Col. 10, Line 22). Hence in combination with Mahdi, if a user of the second device had contact information stored in the database, the associated key can be configured within that database based on that contact or user information.
With respect dependent claim 4, Applicant argues that Leavy does not disclose “comprising, by the first device, configuring the key responsive to identifying a previous communication between the first device and the second device.” Examiner responds that Leavy discloses the claimed limitation by teaching that the database identifies previous communications by including the timestamps of the communications which can further be used to configure the key since all the information associated with the key is also stored in the same database (Col. 9, Line 39 – Col. 10, Line 22).
Conclusion
THIS ACTION IS MADE FINAL. 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NAZIA NAOREEN whose telephone number is (571)270-7282. The examiner can normally be reached M-F: 9:00 - 6:00.
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, Umar Cheema can be reached at 571-270-3037. 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.
/NAZIA NAOREEN/Primary Examiner, Art Unit 2458