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 .
Claims 1-20 are pending for examination.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-8, 11-18 and 20, rejected on the ground of non-statutory double patenting as being unpatentable over Claims 1, 7, 13, 18 and 19 of U.S. Patent No. 11023261. Although the claims at issue are not identical, they are not patentably distinct from each other because they are substantially similar in scope, both share the same inventive concept, both rely on identical messaging and web application security-domain architecture. Accordingly, the claim limitations of the present application represent obvious variation of those in the reference US Patent 11023261.
The table below shows comparison between the instant application and the reference US Patent claims.
19/233,808 (Instant Application)
US 11023261 (Ref. Patent)
Claim 1. A method comprising: receiving, by a first application in a first security domain, a request from a second application in a second security domain to access a virtual currency store,
wherein the first security domain restricts the second application in the second security domain from accessing user data associated with one or more users of the first application;
accessing, by the first application, user account data that comprises a virtual currency balance within the first security domain;
causing display of a virtual currency interface including a plurality of virtual items;
receiving a selection of a virtual item from the plurality of virtual items;
initiating a purchase of the selected virtual item using the virtual currency balance;
adjusting the virtual currency balance in the user account data based on the purchase; and
transmitting a notification of the purchase to the second application in the second security domain while maintaining the restriction on accessing the user data.
Claim 1. A method comprising: …receiving, by the messaging application, a request from the web based application to display a user interface,
wherein the user data is inaccessible from the first security domain;
retrieving, by the messaging application, user data based on the request via a second security domain,
identifying a user interface to display …the user data…displaying, …the identified user interface;
monitoring user interaction with the displayed user interface…
determining, …performing a financial transaction … performing the financial transaction…
Claim 7. …indicate to the web based application a portion of the virtual currency value that has been credited to a virtual currency balance of the user account
transmitting a message to the web based application, the message comprising a response indicating one or more metrics
Claim 2. The method of claim 1, wherein the first application comprises a messaging application operating in the first security domain.
Claim 1. A method, comprising: …a messaging application,
Claim 3. The method of claim 1, wherein the second application comprises a web-based application operating in the second security domain within a web view of a messaging application.
Claim 1. … launching, within a web view of a messaging application, a web based application, the web view executing the web based application within a first security domain;
Claim 4. The method of claim 1, wherein the first security domain comprises an application security domain having access to financial data including the virtual currency balance.
Claim 1. … determining, by the messaging application, that the request from the web based application comprises performing a financial transaction by the messaging application
Claim 5. The method of claim 1, wherein the second security domain comprises a web-based application security domain executed within a web view of the first application, wherein financial data is inaccessible to the web-based application security domain.
Claim 1. user data based on the request via a second security domain, wherein the user data is inaccessible from the first security domain;
Claim 6. The method of claim 1, wherein the virtual currency interface is displayed by the first application based on determining that the second application lacks access to the virtual currency balance in the first security domain.
Claim 1. identifying a user interface to display based on one or more criteria and the user data; displaying, within a session of a user account, the identified user interface
Claim 7. The method of claim 1, wherein initiating the purchase comprises: determining that the request from the second application comprises performing a financial transaction; causing display of a confirmation dialog by the first application prior to performing the financial transaction; and generating transaction results based on user interaction with the confirmation
dialog.
Claim 1. determining, by the messaging application, that the request from the web based application comprises performing a financial transaction by the messaging application; in response to determining that the request from the web based application comprises performing the financial transaction by the messaging application, causing a confirmation dialog to be displayed by the messaging application prior to performing the financial transaction;
Claim 8, authenticating the purchase using credentials… displaying a confirmation dialog… performing a financial transaction… providing transaction result data …while preventing access
Claim 1. causing a confirmation dialog to be displayed… performing a financial transaction by the messaging application… displayed user interface to generate display results … the user data is inaccessible from the first security domain.
Claims 11-18 and 20 are correspond to Claim 13, 18 and 19 of US patent 11023261.
Claims 1-8, 11-18 and 20, rejected on the ground of non-statutory double patenting as being unpatentable over Claims 1-3, 8-10 and 18 of U.S. Patent No. 11599371. Although the claims at issue are not identical, they are not patentably distinct from each other because they are substantially similar in scope, both share the same inventive concept, both rely on identical messaging and web application security-domain architecture. Accordingly, the claim limitations of the present application represent obvious variation of those in the reference US Patent 11023261.
The table below shows comparison between the instant application and the reference US Patent claims.
19/233,808 (Instant application)
US 11599371 (reference patent)
Claim 1. A method comprising:
receiving, by a first application in a first security domain, a request from a second application in a second security domain to access a virtual currency store,
wherein the first security domain restricts the second application in the second security domain from accessing user data associated with one or more users of the first application;
accessing, by the first application, user account data that comprises a virtual currency balance within the first security domain;
causing display of a virtual currency interface including a plurality of virtual items;
receiving a selection of a virtual item from the plurality of virtual items; initiating a purchase of the selected virtual item using the virtual currency balance;
adjusting the virtual currency balance in the user account data based on the purchase;
transmitting a notification of the purchase to the second application in the second security domain while maintaining the restriction on accessing the user data.
Claim 1. A method, comprising:
…receiving, by the messaging application, a request from the web-based application to display a given user interface;
Claim 1. wherein the user data is inaccessible directly by the web-based application
Claim 1. retrieving, by the messaging application, user data based on the request, .. identifying, by the messaging application, a user interface … providing to the user a subset of an
amount of virtual currency associated with a display of the video.
Claim 1. displaying, within a session of a user account, the identified user interface; … and providing to the user a subset of an amount of virtual currency associated with a display
Claim 2. the request …comprises performing a financial transaction by the messaging application; …performing the financial transaction by the messaging application
Claim 1. providing … a subset of an amount of virtual currency… the subset being computed based on the percentage of the video of which the user has watched.
Claim 3. … transmitting a message to the web-based application, the message comprising a response indicating one or more metrics associated with the monitored user interaction.
Claim 2. The method of claim 1, wherein the first application comprises a messaging application operating in the first security domain.
Claim 1. …launching, by a messaging application
Claim 3. The method of claim 1, wherein the second application comprises a web-based application operating in the second security domain within a web view of a messaging application.
Claim 1. launching, …a web-based
application; a request from the web-based application to display a given user interface;
Claim 4. The method of claim 1, wherein the first security domain comprises an application security domain having access to financial data including the virtual currency balance.
Claim 2. …the request from the web-based application comprises performing a financial transaction by
the messaging application..
Claim 5. The method of claim 1, wherein the second security domain comprises a web-based application security domain executed within a web view of the first application, wherein financial data is inaccessible to the web-based application security domain.
Claim 1. user data based on the request, wherein the user data is inaccessible directly by the web-based application
Claim 6. The method of claim 1, wherein the virtual currency interface is displayed by the first application based on determining that the second application lacks access to the virtual currency balance in the first security domain.
Claim 1. generating the identified user interface of the messaging application … displaying, within a session of a user account, the identified user interface; determining a percentage of a video included in the identified user interface of which the user has watched less than an entirety; and providing to the user a subset of an amount of virtual currency
Claim 7. The method of claim 1, wherein initiating the purchase comprises: determining that the request from the second application comprises performing a financial transaction; causing display of a confirmation dialog by the first application prior to performing the financial transaction; and generating transaction results based on user interaction with the confirmation
dialog.
Claim 2. determining, by the messaging
application, that the request from the web-based application comprises performing a financial transaction by
the messaging application; …causing a confirmation dialog to be displayed by the messaging application prior to performing the financial transaction; … the displayed user interface to generate display results.
Claim 8. authenticating the purchase using credentials… displaying a confirmation dialog… performing a financial transaction… providing transaction result data …while preventing access
Claim 2. …causing a confirmation dialog to be displayed … performing the financial transaction by the messaging application …displayed user interface to generate display results.
Claim 1. …user data is inaccessible directly by the web-based application;
Claims 11-18 and 20 are correspond to Claim 8-10 and 18 of US patent 11599371.
Claims 1-5, 7. 11-15, 17 and 20, rejected on the ground of non-statutory double patenting as being unpatentable over Claims 1, 4, 9, 12 and 18 of U.S. Patent No. 12353575. Although the claims at issue are not identical, they are not patentably distinct from each other because they are substantially similar in scope, both share the same inventive concept, both rely on identical messaging and web application security-domain architecture. Accordingly, the claim limitations of the present application represent obvious variation of those in the reference US Patent 12353575.
The table below shows comparison between the instant application and the reference US Patent claims.
19/233,808 (Instant application)
US 12353575 (reference patent)
Claim 1. A method comprising:
receiving, by a first application in a first security domain, a request from a second application in a second security domain to access a virtual currency store, wherein the first security domain restricts the second application in the second security domain from accessing user data associated with one or more users of the first application;
accessing, by the first application, user account data that comprises a virtual currency balance within the first security domain;
causing display of a virtual currency interface including a plurality of virtual items;
receiving a selection of a virtual item from the plurality of virtual items;
initiating a purchase of the selected virtual item using the virtual currency balance;
adjusting the virtual currency balance in the user account data based on the purchase;
transmitting a notification of the purchase to the second application in the second security domain while maintaining the restriction on accessing the user data.
Claim 1. A method comprising: receiving, by a messaging client application in a first security domain, a request from a web-based application in a second security domain to display a video, wherein: the first security domain restricts the web-based application in the second security domain from accessing user data associated with one or more users of the messaging client application
the request comprises a plurality of criteria and a first amount of virtual currency; accessing, by the messaging client application, the user data within the first security domain;
displayed in response to comparing the user data with the plurality of criteria included in the request
determining, …a subset of the first amount of virtual currency within the first security domain based on a robustness of user interactions…
Claim 4. determining, …the request from t…comprises performing a financial transaction …in response …causing a confirmation ..the financial transaction; and monitoring user interaction
adding, …the subset of the first amount of virtual currency to the second amount of virtual currency of the user account data.
reporting the subset of the first amount of virtual currency from the messaging client application to the web-based application.
Claim 2. The method of claim 1, wherein the first application comprises a messaging application operating in the first security domain.
Claim 1. … receiving, by a messaging client application…
Claim 3. The method of claim 1, wherein the second application comprises a web-based application operating in the second security domain within a web view of a messaging application.
Claim 1. receiving, … a request from a web-based application in a second security domain
Claim 4. The method of claim 1, wherein the first security domain comprises an application security domain having access to financial data including the virtual currency balance.
Claim 1. … receiving, by a messaging client application in a first security domain, a request … the request comprises a plurality of criteria and a first amount of virtual currency…
Claim 5. The method of claim 1, wherein the second security domain comprises a web-based application security domain executed within a web view of the first application, wherein financial data is inaccessible to the web-based application security domain.
Claim 1. …the first security domain restricts the web-based application in the second security domain from accessing user data associated with one or more users of the messaging client application…
Claim 7. The method of claim 1, wherein initiating the purchase comprises: determining that the request from the second application comprises performing a financial transaction; causing display of a confirmation dialog by the first application prior to performing the financial transaction; and generating transaction results based on user interaction with the confirmation dialog.
Claim 4. …determining, …that the request from the web-based application comprises performing a financial transaction …in response …, causing a confirmation dialog to be displayed by the messaging client application prior to performing the financial transaction; and monitoring user interaction with the video to generate display results.
Claims 11-15, 17 and 20 are correspond to Claims 9, 12 and 18 of US patent 12353575.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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.
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.
Claims 1, 4, 7-10, 11, 14 and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 20130139220 (Bhanoo et al.).
Regarding Claim 1, Bhanoo teaches a method comprising: receiving, by a first application in a first security domain, a request from a second application in a second security domain to access a virtual currency store, wherein the first security domain restricts the second application in the second security domain from accessing user data associated with one or more users of the first application ([¶ 0008], a request associated with a secure in-application transaction is generated through the client application [i.e., second application],…The request for the secure in-application transaction is submitted …to a first domain. [¶ 0013], the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user. …the in-game upgrade is …a purchase of virtual currency. [¶ 0108], the client application cannot read any values stored by the transaction module [i.e., first application]. [¶¶ 0122-0123], the client application is not permitted to obtain personal information from the transaction database …, the client application can support in-application transactions in a secure manner without having to set up the disclosed secure platform (e.g., secure internet server and the transaction server). … the secure platform can be run by a separate entity);
accessing, by the first application, user account data that comprises a virtual currency balance within the first security domain ([¶ 0013], the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user. …the in-game upgrade is …a purchase of virtual currency);
causing display of a virtual currency interface including a plurality of virtual items ( [¶¶ 0012-0013], a display having a screen real estate. …the client application is manifested on a portion of the screen real estate and the validated transaction module is manifested on a subset of the portion of the screen real estate. This advantageously gives the user of the client application the impression that the in-application transaction is a seamless transaction that is being run from within the client application. …the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user. …the in-game upgrade is …a purchase of virtual currency [¶¶ 0124-0125] in-application transaction is enhanced by creating the appearance that the transaction module is controlled by the client application …The client application uses the application programming interface to allocate a portion of the screen real estate being used by the client application to open up the transaction module. …the transaction module …and the client application, when making the transaction request, specifies the coordinates on the screen where this …interface may open);
receiving a selection of a virtual item from the plurality of virtual items; initiating a purchase of the selected virtual item using the virtual currency balance ([0090], …the client application invokes request module to make a request for a secure in-application transaction. …the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of a user of the client application. Examples of in-game upgrades include, but are not limited to, a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency);
adjusting the virtual currency balance in the user account data based on the purchase ([¶ 0117], The secure interface server creates an entry for the transaction …the unique transaction identifier assigned to the transaction while the transaction server records the status of the transaction (e.g., completed, failed, amount credited, amount debited etc.); and
transmitting a notification of the purchase to the second application in the second security domain while maintaining the restriction on accessing the user data ([¶ 0085], a transaction database …storing a status of a secure in-application transaction. [¶ 0091], unique transaction identifier is used to track the status of the in-application transaction. [¶ 0117], the status of the transaction is stored in transaction database using the unique transaction identifier assigned to the transaction. …The secure interface server creates an entry for the transaction …the unique transaction identifier assigned to the transaction while the transaction server records the status of the transaction (e.g., completed, failed, amount credited, amount debited etc.). [¶¶ 0121-0122], the client application polls the transaction database using the secure interface server to determine the status of the transaction. …unless the source URL of the client application is the URL of the secure interface server, the client application will be unable to interact directly with the transaction server. Thus, the client application would be unable to poll the transaction database using the transaction server …the status of the transaction uniquely associated with the transaction identifier provided by the client application is sent back to the client application running on the client over the Internet or computer network. …the client application is not permitted to obtain personal information from the transaction database …using a unique transaction identifier for the transaction, the client application can determine whether the transaction was successful. Thus, the client application can support in-application transactions in a secure manner without having to set up the disclosed secure platform (e.g., secure internet server and the transaction server). … the secure platform can be run by a separate entity).
Regarding Claim 4, Bhanoo teaches the method of claim 1, wherein the first security domain comprises an application security domain having access to financial data including the virtual currency balance ([¶ 0013], the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user. In some instances, the in-game upgrade is …a purchase of virtual currency. In some instances, the client application is …a financial services application, an accounting application, or a tax preparation application).
Regarding Claim 7, Bhanoo teaches the method of claim 1, wherein initiating the purchase comprises: determining that the request from the second application comprises performing a financial transaction; causing display of a confirmation dialog by the first application prior to performing the financial transaction; and generating transaction results based on user interaction with the confirmation dialog [¶ 0115] a user conducts the transaction using transaction module. During this transaction, the user may enter financial information or other forms of information such as credit card information, debit card information, ATM information, PAYPAL account information. ([¶¶ 0117, 0121-0122], the status of the transaction is stored in transaction database using the unique transaction identifier assigned to the transaction. …the transaction server records the status of the transaction (e.g., completed, failed, amount credited, amount debited etc.) …the client application polls the transaction database using the secure interface server to determine the status of the transaction. …the status of the transaction uniquely associated with the transaction identifier provided by the client application is sent back to the client application running on the client over the Internet or computer network. …the client application is not permitted to obtain personal information from the transaction database. [¶ 0125] the transaction module is a 300 by 400 pixel interface [i.e., dialog] and the client application, when making the transaction request, specifies the coordinates on the screen where this 300 by 400 pixel interface may open) .
Regarding Claim 8, Bhanoo teaches the method of claim 1, wherein initiating the purchase comprises: authenticating the purchase using credentials stored in the first security domain ([¶ 0018], receiving, at the first domain, ..a request from a client application running on a client computer. The request is associated with a secure in-application transaction. The request comprises (i) a credential for the client application, (ii) an identification of a user of the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application. …verifying the credential for the client application against the database of valid application credentials); displaying a confirmation dialog; performing a financial transaction by the first application ([¶¶ 0098-0110], If the application credential provided with the application request is verified …If the application credential provided with the application request received is verified …provides a secure transaction module to …client application …transaction module issues a transaction call while the module is executing in the separate domain-specific security sandbox. [¶ 0125] the transaction module is a 300 by 400 pixel interface [i.e., dialog] and the client application, when making the transaction request, specifies the coordinates on the screen where this 300 by 400 pixel interface may open. [¶ 0115] a user conducts the transaction using transaction module. During this transaction, the user may enter financial information or other forms of information such as credit card information, debit card information, ATM information, PAYPAL account information); and providing transaction result data to the second application while preventing access to virtual currency balance information ([¶¶ 0117, 0121-0122], the status of the transaction is stored in transaction database using the unique transaction identifier assigned to the transaction. …the transaction server 200 records the status of the transaction (e.g., completed, failed, amount credited, amount debited etc.) …the client application polls the transaction database using the secure interface server to determine the status of the transaction. …the status of the transaction uniquely associated with the transaction identifier provided by the client application is sent back to the client application running on the client over the Internet or computer network. …the client application is not permitted to obtain personal information from the transaction database).
Regarding Claim 9, Bhanoo teaches the method of claim 1, further comprising: restricting access by the second application to: virtual currency balance information; virtual currency purchase interfaces; and financial transaction confirmation interfaces ([¶ 0108], the client application loads and executes the transaction module in a domain-specific security sandbox that is dedicated to programs from the domain of secure interface server. …the validated transaction module does not grant the client application the power to introspect the validated transaction module. The client application cannot introspect the transaction module. In other words, the client application cannot read any values stored by the transaction module [i.e., restricted access virtual currency balance information] [¶ 0121], the client application does not ascertain directly from the transaction module whether the in-application transaction was completed, much less whether the in-application transaction was successfully completed [i.e., restricted access financial transaction confirmation interfaces] – it can get status via a separate pulling mechanism. [¶¶ 0124-0125] In-Transaction User Interface. …The client application 34 uses the application programming interface to allocate a portion of the screen real estate being used by the client application 34 to open up the transaction module 38. …the transaction module is a 300 by 400 pixel interface [i.e., virtual currency purchase interfaces] and the client application, when making the transaction request, specifies the coordinates on the screen where this 300 by 400 pixel interface may open. Thus, even though the transaction module is running in its own domain-specific security sandbox, the client application and the transaction module appear to be the same application. Note: Since, Bhanoo’s transaction module does not grant the client application the power to introspect it [¶¶ 0108, 0121], it would be realized that the transaction module’s 300 by 400 pixel interface, through which the user enters purchase and payment information, is likewise restricted from access by the client application).
Regarding Claim 10, Bhanoo teaches the method of claim 9, wherein restricting access by the second application comprises: implementing a security boundary between the first security domain and the second security domain ([0047], a client application makes a request for a transaction module from a first domain. Once the client application receives the transaction module, it is executed in its own domain-specific security sandbox such that the source URL of the transaction module, the URL of the first domain, is preserved. The transaction module completes the transaction by interacting with a second domain that has a cross-domain policy that restricts interaction to those programs and processes whose source URL is the first domain); detecting requests from the second application that attempt to access one or more of the virtual currency balance information, the virtual currency purchase interfaces, or the financial transaction confirmation interfaces ([¶ 0094], the request for the secure in-application transaction is received…[¶¶ 0115, 0125], a user conducts the transaction using transaction module …the client application, when making the transaction request, specifies the coordinates on the screen where this 300 by 400 pixel interface may open. Thus, even though the transaction module is running in its own domain-specific security sandbox, the client application and the transaction module appear to be the same application; redirecting the requests to the first security domain ([¶ 0110], transaction module issues a transaction call while the module is executing in the separate domain-specific security sandbox. The transaction call is issued to a second domain [i.e., redirecting the request]); and providing, from the first application to the second application, transaction result data that excludes the virtual currency balance information ([¶¶ 0117, 0121-0122], the status of the transaction is stored in transaction database using the unique transaction identifier assigned to the transaction. …the transaction server 200 records the status of the transaction (e.g., completed, failed, amount credited, amount debited etc.) …the client application polls the transaction database using the secure interface server to determine the status of the transaction. …the status of the transaction uniquely associated with the transaction identifier provided by the client application is sent back to the client application running on the client over the Internet or computer network. …the client application is not permitted to obtain personal information from the transaction database).
Regarding Claim 11, the claim limitations are identical and/or equivalent in scope to claim 1, therefore, Claim 11 is rejected under the same rationale as claim 1. Examiner further notes, Bhanoo also teaches a system, comprising: hardware processing circuitry; and a hardware memory storing instructions [¶ 0078], as required by Claim 11.
Claims 14, and 17-19 are identical and/or equivalent in scope to claims 4 and 7-9, therefore, Claims 14 and 17-19 are rejected under the same rationale as claim claims 4 and 7-9.
Regarding Claim 20, the claim limitations are identical and/or equivalent in scope to claim 1, therefore, Claim 20 is rejected under the same rationale as claim 1. Examiner further notes, Bhanoo also teaches a non-transitory computer readable storage medium comprising instructions that when executed configure hardware processing circuitry to perform operations [¶ 0160], as required by Claim 20.
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 2, 6, 12 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bhanoo in view of US 20150058923 (Rajagopal et al.).
Regarding Claim 2, Bhanoo teaches the method of claim 1, wherein the first application comprises a messaging application operating in the first security domain ([¶ 0013], the client application is a social networking application), however, Bhanoo does not explicitly teach a messaging application, Rajagopal, in the same of endeavor, teaches wherein the first application comprises a messaging application ([¶ 0042-0043], the secure service environment allows for …the user to login to various items such as their email. The secure service environment then further provides a secure disposable browser such that on the user's local machine, they would see their service web interface presented to them … use the email portal 240).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Rajagopal's secure email portal as the messaging application operating within the first secure domain into Bhanoo’s transaction-sandbox architecture because such incorporation would have yielded the predictable result of a security-domain-isolated messaging channel, making the combination a straightforward application of a known component to achieve its already disclose purpose.
Regarding Claim 6, while Bhanoo teaches lacks access to the virtual currency balance ([¶ 0108], the validated transaction module does not grant the client application the power to introspect the validated transaction module. The client application cannot introspect the transaction module. In other words, the client application cannot read any values stored by the transaction module), however, Bhanoo does not explicitly teach, but Rajagopal, in the same of endeavor, teaches wherein the … interface is displayed by the first application based on determining that the second application lacks access to…the first security domain ([¶¶ 0068-0069], … a user's secure disposable browser is restricted to a certain directory within the overall file system on the authenticated service machine… assign to users upon each session request to establish a session-specific secure jail, and can then create the secure disposable browser within the secure jail … one user's data is not accessible to another user and that one disposable browser or other secure web container cannot be compromised and be used to intercept or corrupt another user's disposable browser or other secure web container operating in another secure jail running on the same authenticated service machine. [0101-0104], The API server validate an API call received from a requesting party application of a requesting party application provider. … The API server validates and processes the API call. …the API server instructs the authenticated service machine to construct a secure web container based on policy records in the requesting party application data store and/or policies in the policy database. …The server may further instruct the authenticated service machine to invoke the secure web container based on the policy record(s) determined… Thus, the sequence is, determine the policy applicable to the second application, then construct/display the secure web container accordingly).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Rajagopal's policy-determination-then-container invocation approach into Bhanoo’s transaction-sandbox architecture because both are address the same underlying problem – preventing a less-trusted client-side application from directly accessing sensitive user or transaction data while still allowing it to initiate a secure transaction through an isolated interface.
Claims 12 and 16 are identical and/or equivalent in scope to claims 2 and 6, therefore, Claims 12 and 16 are rejected under the same rationale as claim claims 2 and 6.
Claims 3, 5, 13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Bhanoo in view of US 20140087883 (Lee et al.).
Regarding Claim 3, Bhanoo teaches the method of claim 1, wherein the second application comprises a web-based application operating in the second security domain ([¶ 0088], runs the client application 34 from a remote application server over the Internet or computer network. In some instances, the client application 34 is a social networking application (e.g., FACEBOOK, MYSPACE)) however, Bhanoo does not explicitly teach, but Lee teaches a web-based application operating …within a web view of a messaging application ([¶¶ 0039-0040], a mobile application for social networking includes an ad for an online property in the form of an embedded mobile ad unit. a mobile application for social networking includes a user navigation menu. In this embodiment, the menu of includes an ad for an online property in the form of an embedded mobile ad unit. In this embodiment, the online property is an interactive mobile game. The ad unit provides the interactive mobile game, which is fully contained within the ad unit. [¶ 0061] builds the content of the unit into the webview of the ad. … methods described herein utilize a webview in which to be delivered).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhanoo’s client application to be implemented as a web-based application delivered with a webview, as taught by Lee, because Bhanoo already discloses obtaining and running the client application from a remote application server over the internet, and Lee’s webview based delivery was a known technique for embedding such remotely served content with the a host application (e.g., a social networking application) to achieve the predictable benefit of a self-contained, more easily updatable and cross-platform interactive/transactional experience without requiring a separate installed native application.
Regarding Claim 5, Bhanoo teaches the method of claim 1, wherein the second security domain comprises a web-based application security domain executed…, wherein financial data is inaccessible to the web-based application security domain ([¶ 0088], runs the client application from a remote application server over the Internet or computer network. In some instances, the client application 34 is a social networking application (e.g., FACEBOOK, MYSPACE). [¶¶ 0122-0123], the client application is not permitted to obtain personal information from the transaction database …, the client application can support in-application transactions in a secure manner without having to set up the disclosed secure platform (e.g., secure internet server and the transaction server). … the secure platform can be run by a separate entity).
however, Bhanoo does not explicitly teach, but Lee teaches a web-based application …executed within a web view of the first application ([¶¶ 0039-0040], a mobile application for social networking includes an ad for an online property in the form of an embedded mobile ad unit. a mobile application for social networking includes a user navigation menu. In this embodiment, the menu of includes an ad for an online property in the form of an embedded mobile ad unit. In this embodiment, the online property is an interactive mobile game. The ad unit provides the interactive mobile game, which is fully contained within the ad unit. [¶ 0061] builds the content of the unit into the webview of the ad. … methods described herein utilize a webview in which to be delivered).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Bhanoo’s client application to be implemented as a web-based application delivered with a webview, as taught by Lee, because Bhanoo already discloses obtaining and running the client application from a remote application server over the internet, and Lee’s webview based delivery was a known technique for embedding such remotely served content with the a host application (e.g., a social networking application) to achieve the predictable benefit of a self-contained, more easily updatable and cross-platform interactive/transactional experience without requiring a separate installed native application.
Claims 13 and 15 are identical and/or equivalent in scope to claims 3 and 5, therefore, Claims 13 and 15 are rejected under the same rationale as claim claims 3 and 5.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-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, ARIO ETIENNE can be reached at 571-272-4001. 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.
/MOHAMMAD YOUSUF A. MIAN/ Examiner, Art Unit 2457
/ARIO ETIENNE/ Supervisory Patent Examiner, Art Unit 2457
Prosecution Insights